Threat modelling is the structured practice of asking four questions about a system before attackers do: what are we building, what can go wrong, what are we doing about it, and did it work. STRIDE and PASTA are frameworks for the second question, not the whole activity. Teams that treat the frameworks as the process end up with impressive diagrams and no security decisions; teams that keep the four questions central ship safer designs in an hour per feature.
This post explains both frameworks honestly, including what they are bad at, then lays out the lightweight threat modelling process we have seen survive real delivery pressure.
What Is Threat Modelling, Concretely?
Strip the methodology branding and threat modelling is a design review with an adversarial lens. Adam Shostack's four-question frame is the durable core:
- What are we working on? A diagram of components, data flows, and trust boundaries: the places where data crosses from less-trusted to more-trusted context.
- What can go wrong? Enumerated threats, using a framework like STRIDE so you do not rely on inspiration.
- What are we going to do about it? Mitigations, each landing in the backlog as a real ticket, or an explicit accepted risk with an owner.
- Did we do a good job? Verification: tests, scanner rules, or pen-test scope derived from the model.
The output that matters is question three. A threat model that produces zero backlog items was either a perfect design or a wasted meeting, and it is rarely a perfect design.
How Does STRIDE Work?
STRIDE, developed at Microsoft in the late 1990s, is a mnemonic for six threat categories. You walk each element of your diagram and ask which apply:
- Spoofing: pretending to be another user, service, or device. Maps to authentication.
- Tampering: modifying data in transit or at rest. Maps to integrity.
- Repudiation: denying an action because there is no trustworthy record. Maps to audit logging.
- Information disclosure: data exposed to the wrong party. Maps to confidentiality.
- Denial of service: exhausting the system's capacity. Maps to availability.
- Elevation of privilege: gaining rights you should not have. Maps to authorization.
STRIDE's strength is that it makes threat enumeration mechanical. A developer with no security background can walk a data-flow diagram element by element and produce a respectable threat list. Its weakness is volume without ranking: STRIDE tells you a threat exists, not whether anyone would bother, so you still need a prioritization pass afterward.
How Does PASTA Work, and When Is It Worth the Weight?
PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage methodology that starts from business objectives and works down: define objectives, define the technical scope, decompose the application, analyze threats, analyze vulnerabilities, model attacks, then analyze risk and impact.
The distinguishing feature is that PASTA is risk-centric rather than category-centric. It forces you to connect threats to business impact and to real attacker behavior, which produces output executives can act on. The cost is that a faithful PASTA run takes days and cross-functional participation, not an hour.
The honest guidance: PASTA earns its weight for a payments platform, a healthcare system, or an annual review of a flagship product. For the feature your team ships next sprint, it is too heavy, and attempting it will convince the team that threat modelling itself is impractical.
What Does a Threat Modelling Process That Ships Look Like?
The pattern that survives is small, recurring, and attached to existing rituals rather than scheduled as a separate ceremony.
Scope it to the change, not the system
Model per feature or per epic, whenever a change touches a trust boundary: new endpoint, new integration, new data category, new authentication path. Thirty to sixty minutes, the engineers building it plus one security-minded facilitator.
Diagram just enough
One whiteboard-grade data-flow diagram with trust boundaries drawn as dotted lines. If the diagram takes longer than ten minutes, the scope is too big.
Enumerate with STRIDE-per-boundary
Walk only the trust boundary crossings, applying the six STRIDE categories to each. This concentrates attention where attacks actually start and keeps the threat count tractable.
Rank by exploitability, then decide
For each threat: mitigate, accept with a named owner, or push to verification. Every mitigation becomes a ticket in the same sprint tooling as feature work. Risk acceptance without a name attached is how findings vanish.
Close the loop with automation
The fourth question is where tooling belongs. Threats you mitigated should map to checks that stay on permanently: authorization tests in CI, SAST and DAST scanning covering the injection and access-control classes, dependency analysis via SCA for the supply-chain threats STRIDE surfaces at build boundaries. The model tells the scanners what matters; the scanners keep the model honest between reviews.
Why Do Threat Modelling Programs Die?
Four recurring causes, all avoidable:
- The deliverable becomes the point. A 40-page document is written once, reviewed never, and outdated by the second sprint. Keep the artifact to a diagram plus a threat table.
- Security runs it alone. If developers do not enumerate the threats themselves, they do not believe the threats. The facilitator guides; the builders find.
- No backlog integration. Findings recorded in a wiki instead of the sprint board are findings scheduled for deletion.
- One framework for everything. STRIDE for routine changes, PASTA-grade analysis for the crown jewels once a year. Forcing either onto the other's job discredits both. Teams building this skill deliberately can start with the secure-design track in our Academy.
FAQ
What is threat modelling in simple terms?
It is a structured design review where a team diagrams what it is building, systematically lists what could go wrong using a framework like STRIDE, decides on mitigations, and verifies the mitigations were implemented.
What is the difference between STRIDE and PASTA?
STRIDE is a lightweight categorization mnemonic for enumerating threats against system components; it takes minutes to hours. PASTA is a seven-stage, risk-centric methodology that ties threats to business impact and simulated attacks; it takes days. STRIDE suits per-feature reviews, PASTA suits high-stakes annual assessments.
When should threat modelling happen?
At design time, before code is written, and again whenever a change crosses a trust boundary: new endpoints, integrations, data categories, or authentication flows. Modelling after implementation still helps, but the cheap fixes have usually already been foreclosed.
Is threat modelling still needed if we run security scanners?
Yes. Scanners find implementation flaws in code that exists; threat modelling finds design flaws such as missing authorization boundaries, unsafe trust assumptions, and unlogged critical actions, which scanners cannot see. The two feed each other: models tell scanners where to focus, and scan findings reveal where the model was wrong.