Threat modelling has a reputation for being heavyweight, and the full methodologies deserve it. But the value is concentrated in the first ninety minutes, and a small team can capture most of it in a session before each significant feature.
Four questions, one whiteboard
- What are we building? Draw the data flow, including every trust boundary it crosses.
- What can go wrong? Walk each boundary and ask who could cross it and with what.
- What are we doing about it? Assign a control or an accepted risk to each item.
- Did we do a good job? Revisit when the design changes materially.
The diagram matters more than the taxonomy. Most real findings come from someone noticing that a service talks directly to a database it should not reach, or that a webhook endpoint has no authentication because it was assumed to be internal.
Findings need owners and dates
A threat model that produces a document produces nothing. Each accepted risk gets a named owner and a review date; each control becomes a ticket in the same backlog as feature work. Security items that live in a separate tracker do not get done.
Prioritise by exploitability and blast radius
Rank by how easily an issue can be reached and how much it exposes, not by CVSS in isolation. An unauthenticated endpoint returning customer records outranks a theoretical timing attack on an internal service every time.
The purpose of a threat model is to change the design. If nothing in the architecture changed, the session was a meeting.