Security7 min read

Threat Modeling

Systematically identify and mitigate security threats during design using STRIDE, data-flow diagrams, and attack trees before code is written.

threat-modelingsecuritystrideappsec

Threat modeling is a structured approach to identifying security threats during the design phase, when they're cheapest to fix. It asks: What are we building? What can go wrong? What are we going to do about it? Did we do a good job?

Model threats at design time, not as a post-launch audit. A two-hour threat modeling session can prevent weeks of incident response. Involve developers, security engineers, and product owners. Document decisions in ADRs.

Workflow

Draw and decompose the systemYou can't find threats in a system you haven't understood and mapped.
Apply STRIDE to each elementSTRIDE ensures systematic coverage of all threat categories.
Prioritize threats with DREAD or risk matrixNot all threats need equal attention; prioritize by impact and likelihood.
Define mitigations for each threatFinding threats without mitigations produces only fear, not security.
Validate and iterateSystems change; a threat model from last year may miss new attack surfaces.

Output Format

DFD with trust boundaries, STRIDE-analyzed threat list, DREAD-prioritized risks, documented mitigations with owners, tracked in security backlog.

Examples

STRIDE on login flow: Spoofing→require MFA; Tampering→sign session tokens; Repudiation→audit log all auth events; Info Disclosure→mask credentials in logs; DoS→rate limit; EoP→validate role on every request

DREAD example: SQL injection via user input: D=3, R=3, E=2, A=3, D=1 = score 12/15 → Critical, fix immediately

Mitigation ADR: "ADR-042: Add CSRF tokens to all state-changing forms. Owner: @security-team. Verified by: automated test in CI."

Edge Cases & Gotchas

Third-party integrations require their own DFD sub-diagrams-treat them as untrusted until proven otherwise
Serverless architectures have different trust boundaries: focus on IAM role permissions and event injection
Threat models for APIs must include broken object-level authorization (BOLA) which STRIDE doesn't naturally surface

When to Break These Rules

For truly trivial internal tools (read-only dashboards with no sensitive data), a lightweight "what could go wrong" checklist replaces a full STRIDE analysis.

Reference Files

OWASP Threat Modeling: https://owasp.org/www-community/Application_Threat_Modeling
OWASP Threat Dragon: https://owasp.org/www-project-threat-dragon/
Microsoft STRIDE: https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
Adam Shostack "Threat Modeling": https://www.threatmodelingbook.com/