ATALAIAMost threat models fail in one of two ways. Either security writes them alone, and they describe a system nobody on the team recognises. Or they arrive late, and they describe a system that has already shipped.
The fix is not a better template. It is a better room.
Who is in the room
Product, because they know what the feature is for and what the business would hate to lose. The dev lead, because they know how it is actually built. Someone from security, because they know how things break. Security champions if you have them.
The hour
- 10 min · draw itOne feature, one board. Boxes for components, arrows for data, dashed lines where trust changes. Keep it ugly and fast.
- 30 min · break itWalk each arrow and ask: who could fake this, change this, read this, block this, or use it to get more access than they should?
- 15 min · rank itImpact times likelihood, roughly. Product decides what the business can live with; security says how hard each one is to exploit.
- 5 min · ticket itEvery threat you keep becomes a ticket with an owner. Abuse cases go to QA as test ideas.
Break it, with STRIDE as a prompt
The six STRIDE letters make good questions for each arrow: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Write every answer down, even the silly ones. The silly ones are often where the real bug hides.
What changes
Developers stop hearing about security for the first time in a pentest report. Product understands why a control matters. Security learns how the system really works. And the threat model lives in the repo, next to the code, where it gets updated.
What to do on Monday
- Pick the next feature with a new external input or a new data store.
- Book one hour with product, the dev lead and security.
- Commit the board photo and the threat list as
docs/threat-model.md.
Where this sits on the line
In the tower (in development):