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.

• ID: security-hardening.infra-monitoring.threat-modeling

• Severity: info

• What to look for: List all security documentation files (threat model, security architecture review, penetration test reports). check for documentation indicating that a security review or threat modeling exercise was completed for the application. Look for a SECURITY.md, threat model documents in docs/, architecture decision records (ADRs) mentioning security, or comments in code describing threat model assumptions.

• Pass criteria: A threat model or security review document exists, covering at minimum: trust boundaries, sensitive data flows, authentication and authorization assumptions, and identified threats with mitigations — at least 1 threat model or security review document must exist. Report: "X security documentation files found."

• Fail criteria: No security review documentation found. No SECURITY.md. No evidence that trust boundaries or threat scenarios have been considered in design documents.

• Skip (N/A) when: The project is a personal project or early prototype with no production users and no handling of sensitive data.

• Detail on fail: "No SECURITY.md, threat model document, or security architecture review found in the repository" or "Application handles payment and health data but no documented security review of trust boundaries"

• Remediation: Start with a lightweight threat model using the STRIDE framework:

  # SECURITY.md
  
  ## Threat Model Summary
  
  ### Trust Boundaries
  - Public internet to load balancer to application servers to database
  - Users are unauthenticated by default; authentication required for all data operations
  - Admin functions require both authentication and admin role
  
  ### Sensitive Data Flows
  - User passwords: hashed with argon2id before storage, never logged
  - Payment data: tokenized via Stripe, raw card data never touches our servers
  - User PII: encrypted at rest, access logged
  
  ### Identified Threats and Mitigations
  | Threat | Category | Mitigation |
  |--------|----------|------------|
  | Credential stuffing | Spoofing | Account lockout, rate limiting |
  | SQL injection | Tampering | Parameterized queries via Prisma ORM |
  | Session hijacking | Elevation | httpOnly cookies, short session TTL |
  | Insider access | Info disclosure | Least privilege DB user, audit logs |
  
  ## Security Contact
  Report vulnerabilities to: security@yourapp.com