Threat modelling for teams that don't have a security team.
A practical, engineering-first approach to threat modelling that fits into a normal product cadence.
Threat modelling has a reputation problem. It's imagined as a heavy, formal process owned by a security team most companies don't have. In practice, a useful threat model can be written in an afternoon by two engineers who understand the system.
The four questions
What are we building? What can go wrong? What are we going to do about it? Did the thing we did actually work? If a team can answer those four questions honestly on a whiteboard, they have a threat model. Everything else is formatting.
Where it lives
Threat models belong in the same repo as the code they describe. They rot the moment they live in a slide deck. We treat them like architecture documents — versioned, reviewed, and updated when the system changes.