The threat modeling process is a structured way to find security problems in a system's design before they become vulnerabilities in its code. It runs in five steps: scope the system, diagram how data moves through it, enumerate what can go wrong (usually with STRIDE), decide what to do about each threat, and validate that the decisions actually happened. Adam Shostack's four questions — what are we building, what can go wrong, what are we going to do about it, did we do a good enough job — are the whole method in miniature. This guide turns them into a process you can run this week.
Step 1: What are we building? Scope and describe the system
Pick a bounded target: one service, one feature, one data flow. "Threat model the platform" produces a mural; "threat model the new payment webhook handler" produces decisions. Gather the people who actually know the system — the engineers building it, someone who understands the infrastructure, ideally the product owner — and write down: what the component does, what data it touches and how sensitive that data is, who its legitimate users are, and what it connects to. Timebox this step aggressively; twenty minutes of shared context beats two weeks of documentation nobody reads.
Step 2: How does data actually move? Draw the diagram
Draw a data flow diagram (DFD) with four kinds of elements: external entities (users, third-party services), processes (your services), data stores (databases, queues, caches, buckets), and the data flows between them. Then add the most important ink on the page: trust boundaries — every place where data crosses from one level of trust to another. Browser to API. API to database. Your service to a vendor's webhook. Internal network to cloud provider.
Trust boundaries are where threats live, because they are where assumptions change: on one side you control the input, on the other you do not. A whiteboard photo is a perfectly adequate artifact; the conversation while drawing it is the actual work. Teams routinely discover during this step that the architecture diagram everyone believed was wrong — an undocumented admin path, a cache holding data it should not, a service calling home nobody remembered.
Step 3: What can go wrong? Enumerate threats with STRIDE
Now walk the diagram, and at each element — especially each trust boundary crossing — ask what could go wrong. STRIDE gives you six prompts so you do not stare at a blank page:
- Spoofing: can something pretend to be a user, service, or server here? (Stolen tokens, unauthenticated internal endpoints.)
- Tampering: can data be modified in flight or at rest? (Unsigned webhooks, mutable build artifacts.)
- Repudiation: can an actor deny an action because nothing logged it?
- Information disclosure: can data leak? (Verbose errors, unencrypted flows, overly broad query responses.)
- Denial of service: can this element be exhausted or wedged? (Unbounded uploads, missing rate limits, recursive processing.)
- Elevation of privilege: can a low-privilege actor gain higher privilege? (Injection flaws, confused-deputy patterns, missing authorization checks.)
Record every credible threat with its location: "an attacker who obtains a session token can replay it indefinitely because tokens never expire — boundary: browser to API." Aim for specific and falsifiable, not generic. A one-hour session on a scoped feature typically yields ten to twenty-five threats worth writing down. Alternative framings exist — attack trees, PASTA for risk-centric analysis, LINDDUN for privacy — but STRIDE-over-a-DFD is the right default for engineering teams starting out.
Step 4: What are we going to do about it? Rank and respond
For each threat, pick one of four responses: mitigate (add a control), eliminate (remove the feature or flow that creates the threat — the most underused option), transfer (push it to a component or party better placed to handle it), or accept (document that the risk is tolerable, with a named owner and a review date).
Rank before you fix. A lightweight impact-times-likelihood scoring is enough to order the list; what matters is that the top items become real, tracked engineering work — tickets in the same backlog as everything else, not rows in a spreadsheet that dies after the meeting. This is also where threat modeling connects to your scanning stack: design-level mitigations get verified by implementation-level tools, and several threat classes ("dependency compromise," "known-vulnerable component") route directly into software composition analysis and SAST policy rather than into custom code.
Step 5: Did we do a good enough job? Validate the threat modeling process
Validation has two halves. First, check the work: does the diagram still match what was built, did every high-ranked threat's mitigation actually ship, and can you test it? Penetration tests and DAST scans are strongest when aimed at the specific threats your model predicted — the model becomes the test plan. Second, check the process: when the system changes in a way that moves trust boundaries (new endpoint, new data store, new third-party integration), the model should be revisited. The practical trigger is a pull-request checklist question — "does this change cross or create a trust boundary?" — rather than a calendar. A threat model is a living artifact tied to architecture, not a compliance document tied to a date.
FAQ
What are the main steps in the threat modeling process?
Five steps: scope and describe the system, diagram data flows and trust boundaries, enumerate threats against the diagram (typically with STRIDE), decide and rank responses (mitigate, eliminate, transfer, or accept), and validate both the mitigations and the model itself as the system evolves.
How long does threat modeling take?
For a scoped feature or service, a focused 60-to-90-minute session with the right people yields most of the value. Whole-system models for critical platforms take longer, but the discipline of small, frequent sessions scoped to changes outperforms rare, large ones.
Do we need special tools for threat modeling?
No. A whiteboard, the STRIDE mnemonic, and a ticket tracker are sufficient. Dedicated tools (OWASP Threat Dragon, Microsoft Threat Modeling Tool) help with diagram management at scale, but tooling is never the bottleneck — getting the right engineers in the room is.
When should threat modeling happen in the development lifecycle?
At design time, before code exists, when changes are cheapest — and again whenever a change creates or crosses a trust boundary. Modeling after release still has value (it directs testing and hardening) but loses the chance to eliminate threats structurally.