Threat modeling or security architecture review completed

Shipping without a threat model means trust boundaries, sensitive data flows, and high-risk attack vectors have never been explicitly identified. NIST 800-53 RA-3 requires threat risk assessment as a foundational security activity; PL-2 requires security plans that address identified threats. ISO 27001:2022 A.5.8 requires information security to be integrated into architecture. Without documented threat analysis, developers don't know which components are high-risk, testers don't know what to probe, and incident responders don't know what could have been compromised. This is especially acute for AI-generated codebases where the developer may not have consciously designed the security architecture.

Create a SECURITY.md at the repository root using the STRIDE framework as a starting point:

## Threat Model Summary

### Trust Boundaries
- Public internet → load balancer → application → database
- Unauthenticated by default; auth required for all data writes

### Sensitive Data Flows
- Passwords: argon2id hashed, never logged
- Payment data: Stripe tokenization; raw cards never reach the server

### Threats and Mitigations
| Threat | Category | Mitigation |
|--------|----------|-----------|
| Credential stuffing | Spoofing | Rate limiting + account lockout |
| SQL injection | Tampering | Prisma ORM parameterized queries |
| Session hijacking | Elevation | httpOnly cookies, 30-min TTL |

## Security Contact
security@yourapp.com

Review and update this document when adding new data categories, external integrations, or authentication flows.