| name | threat-modeling |
| description | Performs STRIDE-style threat modeling on features and systems with ranked mitigations and residual risk. Use before shipping new surfaces, auth flows, or third-party integrations. |
Threat modeling
Purpose
Identify threats at trust boundaries, propose mitigations, and rank residual risk so teams can decide what must ship-block vs follow-up vs accepted risk.
When to Use
- User asks for threat model, STRIDE review, or security design review.
- New auth flows, APIs, admin tools, or third-party integrations.
- Pre-ship security sign-off on a feature or architecture change.
When NOT to Use
- Vulnerability scanning only → snyk, flag-security-issues.
- Incident postmortem → postmortem-authoring.
- Penetration test execution without design context.
Expected Outcome
- Ranked threat list with asset, threat, impact/likelihood, mitigation, residual risk, owner.
- Clear ship/no-ship recommendations for must-fix items.
Inputs to Gather
- Architecture diagram or data-flow description.
- Trust boundaries (Internet, VPC, admin, third parties).
- Authn/z model, data classification, and compliance constraints.
- Existing controls (WAF, mTLS, rate limits).
Workflow
- Scope the feature/system and draw trust boundaries.
- Apply STRIDE (or agreed framework) per component/data flow.
- For each threat: asset, threat, likelihood/impact, mitigation, residual risk.
- Rank: must-fix before ship, follow-up, accepted risk (with owner).
- Link mitigations to tickets/docs when tools available.
Domain guidance
Use a structured lens (e.g. STRIDE) on trust boundaries: authn/z, data flows, third parties, admin paths.
