OWASP threat modeling: the four questions and core methodologies
Threat modeling is the practice of building a model of a system from a security angle, using that model to find the threats specific to it, and deciding what to do about each one — rather than starting from a generic list of known attacks and hoping it happens to fit. OWASP's community page puts it plainly: threat modeling works "to identify, communicate, and understand threats and mitigations within the context of protecting something of value." OWASP does not publish one single official "OWASP Threat Modeling" standard; instead, its community page and its Cheat Sheet Series' Threat Modeling Cheat Sheet both point to the same external four-question framework and the same handful of named methodologies, which is the shape this guide follows.
The four questions underneath every methodology
Both OWASP sources trace threat modeling's core logic to the Threat Modeling Manifesto, published by a working group of 15 practitioners (including Adam Shostack, Zoe Braiterman, Jonathan Marcil, Stephen de Vries and Irene Michlin). Its four questions, quoted directly: "What are we working on?", "What can go wrong?", "What are we going to do about it?", and "Did we do a good enough job?" OWASP's community page restates these as four practical steps — assess scope, identify what can go wrong, identify countermeasures or manage risk, and assess the work — and every named methodology below is really just a different technique for answering question two, "what can go wrong," within that same four-step shape.
Named methodologies, and what each is actually for
The OWASP Cheat Sheet Series' Threat Modeling Cheat Sheet lists several methodologies side by side, each better suited to a different kind of system or a different audience:
| Methodology | What it's for |
|---|---|
| STRIDE | Microsoft's six threat categories — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — applied to a system's components and data flows |
| PASTA | Connects business objectives and technical requirements to application threats; useful for showing direct business impact |
| Attack Trees | Decomposes an attacker's ultimate goal into the alternative or required paths needed to reach it |
| LINDDUN | Privacy-specific threats (Linking, Identifying, Non-repudiation, Detecting, Data disclosure, Unawareness, Non-compliance), not security threats |
| OCTAVE | Organization-wide risk assessment and security strategy for critical assets |
| VAST | Keeps separate application and operational threat models embedded directly in normal development workflows |
There is no single methodology OWASP presents as universally correct. STRIDE is the most commonly reached-for starting point for a discrete system or data flow diagram; LINDDUN is the one to add specifically when personal data is in scope and the concern is privacy rather than confidentiality or availability.
Threat modeling is a practice, not a deliverable
The Cheat Sheet states threat modeling is ideally performed early in the SDLC, particularly at the design phase, and that it "should be ongoing — not a one-time activity." The Threat Modeling Manifesto's own stated values echo this directly, listing "continuous refinement over single delivery" and framing the practice as a "journey of understanding" rather than a single point-in-time snapshot. The Manifesto also names anti-patterns worth avoiding by name: the "hero threat modeler" who tries to do it alone, "admiration for the problem" (endless analysis without deciding what to do about it), and the pursuit of a "perfect representation" of the system instead of a useful-enough one.
A workable starting point
- Start from the four questions, not from a methodology name. "What are we working on, what can go wrong, what are we doing about it, did we do a good enough job" works before a team has picked STRIDE, PASTA or anything else — the methodology is just how question two gets answered systematically.
- Pick STRIDE by default for a discrete system or data-flow diagram, and add LINDDUN specifically when the system handles personal data and privacy threats are in scope alongside security ones.
- Treat the output as a living model, not a one-time report. Revisit it when the architecture, a major integration, or the deployment environment changes — a model that is never updated eventually describes a system that no longer exists.
- Avoid the Manifesto's named anti-patterns: don't let one person own threat modeling alone, don't let analysis replace deciding on mitigations, and don't hold out for a perfect model of the system before acting on what it already shows.
SoftWSP's device and firmware security reviews build a concrete asset and data-flow picture first — the same input a STRIDE or attack-tree exercise needs — so threat modeling has something real to work from: see device firmware security.
This guide summarises public OWASP community and Cheat Sheet Series pages and the Threat Modeling Manifesto, as checked on 28 October 2026. OWASP content is used under its CC BY-SA 4.0 licence with attribution; this guide does not constitute security or compliance advice.
Frequently asked questions
What is threat modeling, per OWASP?
OWASP's community page defines it as working "to identify, communicate, and understand threats and mitigations within the context of protecting something of value," while the OWASP Cheat Sheet Series' Threat Modeling Cheat Sheet describes it as "a structured, repeatable process used to gain actionable insights into the security characteristics of a particular system." Both sources frame it the same way: start from a model of the system, use that model to find the threats relevant to it, then decide what to do about each one — rather than starting from a generic checklist of attacks.
What are the four key questions of threat modeling?
OWASP's community page and the Cheat Sheet both attribute the same four-question framework to the **Threat Modeling Manifesto**, a set of values and principles published by a working group of 15 practitioners including Adam Shostack, Zoe Braiterman, Jonathan Marcil, Stephen de Vries and Irene Michlin, among others. The four questions, verbatim: "What are we working on?", "What can go wrong?", "What are we going to do about it?", and "Did we do a good enough job?" OWASP's own community page maps these onto four practical steps — assess scope, identify what can go wrong, identify countermeasures or manage risk, and assess the work — and treats the questions as the reusable backbone underneath whichever specific methodology a team picks.
What is STRIDE, and how does it differ from PASTA, Attack Trees and LINDDUN?
The OWASP Cheat Sheet Series' Threat Modeling Cheat Sheet names several methodologies side by side, each suited to a different angle on "what can go wrong." **STRIDE** is a Microsoft-developed framework that sorts threats into six categories — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege — applied systematically to a system's components and data flows. **PASTA** (Process for Attack Simulation and Threat Analysis) "connects business objectives and technical requirements to application threats," useful when a team needs to show direct business impact. **Attack Trees** decompose an attacker's ultimate goal into the alternative or required paths needed to reach it. **LINDDUN** targets privacy-specific concerns instead of security ones (Linking, Identifying, Non-repudiation, Detecting, Data disclosure, Unawareness, Non-compliance). The Cheat Sheet also lists **OCTAVE** (organization-wide risk assessment) and **VAST** (separate application and operational threat models inside normal development workflows) as further options — there is no single methodology OWASP endorses as universally correct; the choice depends on what question a team is actually trying to answer.
When should a team threat model, and is it a one-time activity?
No. The OWASP Cheat Sheet Series states threat modeling is ideally performed early in the SDLC, particularly during the design phase, and that it "should be ongoing — not a one-time activity" as systems evolve. This mirrors the Threat Modeling Manifesto's own values, which include "continuous refinement over single delivery" and frame threat modeling as a "journey of understanding" rather than a one-off security/privacy snapshot. A model built once at design time and never revisited drifts out of sync with the system it describes as features, integrations and deployment environments change.