Threat modeling

Do this

1. Scope one change and check the triggers

   Model one feature or change, not the whole estate. Hold a session when a story adds or changes a trust boundary, authentication, authorization or tenant rules, a data store or sensitive data, an external integration, money movement, an admin path or secrets. When you extend an application, OWASP SAMM suggests looking only at the new functions.

2. Draw the data flow and the trust boundaries

   Show external entities, processes, data stores and the flows between them, and mark each trust boundary: internet to API, service to database, your cloud account to a SaaS provider. Every store needs a process that writes it and one that reads it. Add background jobs, admin and support tools and partner callbacks, which teams often forget.

3. Ask what can go wrong at each element

   Walk STRIDE over each element, using its six letters as prompts. Use an attack tree for one high-value goal such as fraud, and LINDDUN when the feature collects, links or shares personal data. The threat pattern library (Threat pattern library for threat modeling) lists the patterns that recur, such as a caller-supplied identity on a boundary flow.

4. Decide a response for each threat

   The OWASP cheat sheet lists four responses: mitigate, eliminate, transfer or accept. Give each threat you act on an owner. Transfer does not reduce the harm itself, so name who still owns the residual controls, and have accepted risks approved by someone with the authority to accept them, with a date to revisit.

5. Turn mitigations into requirements and tests

   Each mitigation becomes a security requirement (Security requirements) and a test named after the threat, such as T4: an edit after approval returns 409. Track the work in the normal backlog; OWASP SAMM recommends feeding threat modeling output into defect management.

6. Keep the model next to the code

   Save the diagram and the threat records where the team can update them, ideally in the repository, so a pull request that changes a flow changes the model too. Tools such as OWASP Threat Dragon, OWASP pytm or the Microsoft Threat Modeling Tool help; a whiteboard photo and a text file also work. Always keep the outcome.

7. Check you did a good enough job

   Compare the diagram with the deployed system, confirm that every flow crossing a boundary was considered and every threat has a response, and run the mitigation tests. Then hand the model to the security design review (Security design review) and re-run the session when a trigger from the first step recurs.

Common mistakes

• Modeling the whole estate at once. The session never finishes; scope it to one change and finish it.
• Treating a tool's generated threat list as the model. Tools produce generic findings and miss business rules such as who may approve what.
• Arguing whether a threat is tampering or elevation of privilege. The category does not change the fix, so use the letters as prompts.
• Relying on one expert. The Threat Modeling Manifesto names this the Hero Threat Modeler anti-pattern: everyone can and should do threat modeling.
• Closing threats without tests. A mitigation that no test checks can disappear in the next refactor without anyone noticing.
• Filing the diagram and never revisiting it. The system drifts from the model, and new boundaries go unexamined.

STRIDE's six categories

Each STRIDE category is the violation of one security property. Ask each one of every element in the diagram, then argue about the threat, not its letter.

Tools and guides

• Workflow: Review a design
• Choose a threat modeling method and turn its findings into tests

  Use the four-question frame to scope a design, pick STRIDE, attack trees, LINDDUN or PASTA by the question you need answered, and leave behind threat records and abuse-case tests the team can run.

• Threat pattern library for threat modeling

  Thirty-two recurring threat patterns grouped by identity, authorization, parsers, concurrency, integrations, data exposure, supply chain, availability and AI agents, each with where it shows up on a data-flow diagram, mitigations, a verification step and STRIDE, CWE and CAPEC links, plus a YAML catalog and a script that lists patterns per diagram element.

• Review tenant boundaries before implementation

  Trace tenant identity through requests, data stores, caches, jobs, and administration, then turn plausible isolation failures into tests.

• Worked threat model: an LLM agent with tools

  A complete worked threat model for an LLM agent with tools: the data-flow diagram, the threats from prompt injection, excessive agency, data exfiltration, confused-deputy and memory poisoning, and the mitigations, mapped to the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications 2026.

Standards

NIST SSDF 1.1

PW.1 Design Software to Meet Security Requirements and Mitigate Security Risks

OWASP SAMM 2

Threat Assessment

Sources

1. Threat Modeling Manifesto
2. OWASP Threat Modeling Cheat Sheet
3. Microsoft Threat Modeling Tool: threats and the STRIDE model
4. Microsoft: Uncover Security Design Flaws Using the STRIDE Approach (MSDN Magazine). November 2006.
5. OWASP SAMM: Threat Assessment, stream B (Threat Modeling)
6. LINDDUN privacy threat types
7. OWASP Threat Dragon
8. OWASP pytm
9. NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.
10. OWASP Top 10:2025 A06 Insecure Design