Threat modelling a feature in an hour

Threat modelling has a reputation for being slow, formal and full of diagrams. It does not need to be. The most useful threat models are short conversations with the people building a feature, held early enough that changes are still cheap.

The four questions

1. What are we building? Draw the feature: users, services, data stores and the lines between them.
2. What can go wrong? Walk each line and ask who could abuse it, and how.
3. What are we going to do about it? Pick fixes, accept risks or move them to the backlog.
4. Did we do a good job? Agree when you will look again.

Running the hour

• 10 minutes: an engineer draws the feature. You ask questions and do not correct.
• 25 minutes: walk the drawing. Where does untrusted input enter? Where does data cross a trust boundary? Who checks permissions, and where?
• 15 minutes: list what could go wrong and sort it into fix now, fix later and accept.
• 10 minutes: name an owner for each fix and write it in the team’s own tracker.

For prompts while walking the drawing, use a known list. The OWASP Top 10 for web apps, the OWASP API Security Top 10 for APIs and the OWASP Top 10 for LLM Applications for AI features all give you a vocabulary the team can look up later.

What not to do

• Do not bring a finished threat model and ask them to sign it. They will not own it.
• Do not list every possible threat. Ten real ones beat fifty theoretical ones.
• Do not file the results in a security-only tool. Use the backlog the team already works from.

Rule of thumb:If you can only threat model one feature this month, choose the one that handles sensitive data and ships soonest. Late changes cost more, and sensitive data raises the stakes.

Keep a copy of each drawing. Over a few months they become a map of your systems that is more current than any architecture document, because the people who built the systems drew them.