Threat modeling is the practice of asking, before something ships, “how could this be attacked, and what are we doing about it?” It's the cheapest security work you will ever do: a design flaw found on a whiteboard costs a conversation; the same flaw found in production costs an incident, a rewrite, and sometimes a disclosure.
Yet most teams never start, because threat modeling has a reputation problem — it sounds like something you need specialists and heavyweight process for. You don't. The whole discipline compresses into four questions, best known from security author Adam Shostack's work:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
Everything below is those four questions with a clock on them.
Before the session: 30 minutes of prep
One person (the facilitator — a tech lead works fine) does three things ahead of time:
- Pick a narrow scope. Not “our platform” — one feature, one service, one flow. “The new payment webhook handler” is a great first target. Small scope is what makes the 90 minutes work.
- Sketch the system on one page. Boxes for components, arrows for data flows, cylinders for data stores, stick figures for humans. Then draw dashed lines wherever trust changes — internet to your API, your API to the database, third-party services. Those dashed lines are where attacks live.
- Invite the right five-ish people. The engineers building it, someone who understands the data, someone who can speak for operations. No spectators.
The 90-minute agenda
| Time | What happens |
|---|---|
| 0–15 min | Walk the diagram together. Fix it live — someone will immediately say “that's not how it works,” and that correction is already value. |
| 15–45 min | Brainstorm what can go wrong, walking each trust boundary with the STRIDE prompts below. Quantity over quality; no fixing allowed yet — capture threats as one-liners. |
| 45–70 min | Prioritize. For each threat, gut-call impact (bad / very bad / existential) and likelihood (plausible / stretch). Sort. Resist scoring frameworks for now — ranking beats rating. |
| 70–90 min | Decide. For the top five only: mitigate, accept (say so out loud, write it down), or investigate. Every decision gets an owner and lands in the backlog before the meeting ends. |
STRIDE: six prompts that unlock the brainstorm
STRIDE is a checklist of attack categories developed at Microsoft in the late '90s — still the fastest way to get a room full of engineers generating threats. For each component and boundary, ask:
| Letter | Category | The plain-language question |
|---|---|---|
| S | Spoofing | Could someone pretend to be a user, a service, or us? What actually proves identity here? |
| T | Tampering | Could data be modified in transit or at rest without us noticing? |
| R | Repudiation | If someone did something malicious here, could they deny it? Would our logs even show it? |
| I | Information disclosure | What's the worst data this component could leak, and to whom? |
| D | Denial of service | What happens if this is flooded, or simply goes away for an hour? |
| E | Elevation of privilege | Could a normal user end up doing admin things? Could a compromised component reach things it shouldn't? |
When the room goes quiet, point at one arrow on the diagram and ask “who can send this request, and how do we know?” That single question reliably restarts the conversation.
Turning threats into actual work
A threat model that lives in a document is decoration. The output of your session is backlog items, written like any other engineering work:
- The threat: “Webhook endpoint accepts unsigned payloads, so anyone who finds the URL can mark orders as paid.”
- The mitigation: “Verify the provider's HMAC signature; reject on mismatch.”
- Acceptance criteria: “Unsigned or tampered payloads return 401 and raise an alert; valid payloads process as before. Covered by tests.”
File the top five, not all forty. Five tickets that ship beat a beautiful risk register that doesn't.
Five ways teams fumble the first session
- Boiling the ocean. Modeling the whole architecture at once produces a wall of vague threats and no decisions. Narrow scope, always.
- Tool-first thinking. Buying a threat-modeling platform before the team has the habit is backwards. Whiteboard first; tools once the practice sticks.
- Making it a security-team ritual. If security people model alone, the builders never internalize the thinking — and the model drifts from reality within a sprint. Engineers in the room, every time.
- Once and never again. A threat model is a snapshot. Architecture changes; the model must move with it (see below).
- Admiring the problem. Sessions that end with insights but no owners produce nothing. No item leaves the room without a name on it.
Keeping it alive after the first win
The full session is for new systems and big changes. The habit that compounds is smaller: a 15-minute delta review whenever a design introduces a new external interface, a new data store, a new third-party dependency, or a change to authentication. Same four questions, tiny scope. Many teams simply add a line to their definition of ready for significant features: “threats considered — yes/no, and by whom.”
Run the 90-minute session once a quarter per major system, delta reviews in between, and within a year the four questions stop being a meeting — they become how your engineers think while they design. That's the actual goal.
Your first-session checklist
- Scope chosen: one feature or service, not the whole platform
- One-page diagram drawn, trust boundaries marked with dashed lines
- Builders in the room (≤6 people), 90 minutes booked
- Threats brainstormed per boundary with the STRIDE prompts
- Top five ranked by impact × likelihood — gut calls, not scores
- Each of the five: mitigate / accept / investigate, with an owner
- Tickets in the backlog before the room empties
- Delta-review trigger agreed for future design changes