Most threat models die in a Confluence page nobody opens twice. A team blocks a room for three hours, draws a beautiful data-flow diagram, argues about nation-state attackers, and produces a PDF that ages like milk. Two sprints later the architecture has moved, the diagram is wrong, and the "action items" never became tickets.
The problem isn't threat modeling. It's that most teams treat it as an event instead of a habit — and never connect the whiteboard to the one place engineering work actually lives: the backlog.
Threat modeling is four questions, not a framework
Strip away the acronyms and the whole practice collapses into four questions Adam Shostack made famous, and I've never found a reason to complicate them:
- What are we building? A diagram simple enough to draw from memory. Boxes, arrows, and trust boundaries — where data crosses from something you control to something you don't.
- What can go wrong? Walk each boundary and each data flow. STRIDE is a fine prompt here, but plain "how would I abuse this?" gets you 80% of the way.
- What are we going to do about it? This is the step everyone skips. Each real threat becomes a decision: mitigate, accept, or transfer.
- Did we do a good job? Revisit when the design changes, not on a calendar.
You don't need a tool. In my engagements the highest-signal sessions used a whiteboard, a photo of it, and one person willing to say "that's not actually exploitable, next."
Scope it to a feature, timebox it to an hour
Modeling "the whole platform" is how you get the useless PDF. Model the thing you're actually shipping this quarter: the new file-upload flow, the partner API, the password-reset path. A tight scope means the diagram fits on one board and the team can hold the whole thing in their heads.
Run it early — during design, before the code is written, when changing a trust boundary costs a conversation instead of a refactor. Invite the people who know where the bodies are buried: one backend engineer, one frontend, whoever owns the infra, and ideally someone from security who acts as a facilitator, not a gatekeeper.
A threat model that takes longer to produce than the feature it protects will not be repeated. Optimize for repeatable, not exhaustive.
Sixty to ninety minutes, one feature, three or four trust boundaries. If you find more than a dozen credible threats, that's a signal the design is too complex — which is itself a finding worth acting on.
The step that matters: whiteboard to backlog
Here's where good intentions go to die. You leave the room with fifteen "concerns" and no owner. The fix is mechanical: every threat you decide to mitigate becomes a backlog item before anyone leaves the room.
Write them like real work, not like audit findings. Bad: "SQL injection risk." Good: "Parameterize the report-search query and add a test that fails on a raw string concatenation." A ticket a developer can pick up without a translation layer.
What actually goes into the backlog
- Mitigations — concrete engineering tasks, sized and prioritized alongside feature work, not in a separate "security backlog" that starves.
- Accepted risks — written down with a name and a date. "We accept unauthenticated read access to public listings — M.A., 2026-07." Silent acceptance is how you end up explaining a breach to a regulator.
- Assumptions to verify — "we assume the gateway strips this header." Half of these turn out false. Make them tickets too.
Tag them so you can find them later. Link the ticket back to the diagram photo. When a mitigation competes with a feature in planning, at least the trade-off is visible instead of invisible.
Make it a habit, not a heroic event
The teams that get value out of this don't run an annual security offsite. They spend twenty minutes on threats in the design review for anything touching auth, money, PII, or a new external integration. It becomes as normal as writing tests.
A few things that keep it alive:
- A definition of done that includes it. "Design reviewed for security threats" as a checkbox on features above a certain risk tier.
- A living diagram, not a frozen one. Keep it in the repo next to the code. A rough diagram that's current beats a gorgeous one that's a year stale.
- Facilitation over policing. The security person's job is to ask sharp questions, not to hand down a verdict. The team owns the model.
Where to start Monday
Pick one feature currently in design. Book sixty minutes. Draw the boxes and the trust boundaries, walk each one asking "how would I abuse this," and before anyone stands up, turn every agreed mitigation into a ticket with an owner. Skip the perfect diagram. Skip the exhaustive attacker taxonomy.
The goal was never a beautiful document. It was a handful of tickets in this sprint that make the next breach someone else's story. If your threat modeling doesn't change the backlog, it didn't happen.