Iron Law: NO ARCHITECTURE REVIEW WITHOUT THREAT MODELING FIRST
Every new feature, service, or architectural change requires a threat model before implementation begins.
When to Use
- New feature or service design → STRIDE analysis + DFD
- Architecture change → full DFD analysis of affected components
- Production security incident → post-incident threat review
- Security audit preparation → staleness check on all threat models
Process
- Load methodology — Read
references/stride-methodology.md for STRIDE matrix, DFD element mapping, risk scoring, and output template
- Load control library — Read
references/threat-mitigation-mapping.md for control categories, the 16-control lookup table, and coverage scoring
- Model the system — Identify assets, trust boundaries, DFD elements, and interactions
- Run STRIDE — Apply per-element and per-interaction analysis using the methodology reference
- Map mitigations — Select controls from the library; verify defense-in-depth across layers
- Score and report — Calculate
risk = impact × likelihood, document residual risks
References
| File |
Content |
Load When |
references/stride-methodology.md |
STRIDE matrix, DFD mapping, risk scoring formula, output template |
STRIDE analysis, DFD mapping, risk scoring |
references/threat-mitigation-mapping.md |
Control library (16 controls), coverage scoring, budget prioritization |
Selecting security controls, budget prioritization |
Error Handling
If architecture documents are missing, reconstruct system topology from the codebase using Grep/Glob.
If a component lacks context for threat analysis, flag it explicitly rather than guessing.
1---2name: threat-modeling3description: Iron Law: NO ARCHITECTURE REVIEW WITHOUT THREAT MODELING FIRST4---56## Iron Law: NO ARCHITECTURE REVIEW WITHOUT THREAT MODELING FIRST78Every new feature, service, or architectural change requires a threat model before implementation begins.910## When to Use1112- New feature or service design → STRIDE analysis + DFD13- Architecture change → full DFD analysis of affected components14- Production security incident → post-incident threat review15- Security audit preparation → staleness check on all threat models1617## Process18191. **Load methodology** — Read `references/stride-methodology.md` for STRIDE matrix, DFD element mapping, risk scoring, and output template202. **Load control library** — Read `references/threat-mitigation-mapping.md` for control categories, the 16-control lookup table, and coverage scoring213. **Model the system** — Identify assets, trust boundaries, DFD elements, and interactions224. **Run STRIDE** — Apply per-element and per-interaction analysis using the methodology reference235. **Map mitigations** — Select controls from the library; verify defense-in-depth across layers246. **Score and report** — Calculate `risk = impact × likelihood`, document residual risks2526## References2728| File | Content | Load When |29|------|---------|-----------|30| `references/stride-methodology.md` | STRIDE matrix, DFD mapping, risk scoring formula, output template | STRIDE analysis, DFD mapping, risk scoring |31| `references/threat-mitigation-mapping.md` | Control library (16 controls), coverage scoring, budget prioritization | Selecting security controls, budget prioritization |3233## Error Handling3435If architecture documents are missing, reconstruct system topology from the codebase using Grep/Glob.36If a component lacks context for threat analysis, flag it explicitly rather than guessing.
kumaran-is