# Threat modeling or security architecture review completed

- **Pattern:** `ab-002417` (`security-hardening.infra-monitoring.threat-modeling`)
- **Severity:** info
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-002417
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-002417)

## Why it matters

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.

## Severity rationale

Info because threat modeling absence is a process gap, not an immediate vulnerability — but it means all other security controls were implemented without a map of what they are protecting against.

## Remediation

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

```markdown
## 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.

## Detection

- **ID:** `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:

  ```markdown
  # 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
  ```

---

## External references

- nist RA-3
- nist PL-2
- iso-27001 A.5.8

Taxons: operational-readiness

HTML version: https://auditbuffet.com/patterns/ab-002417