Threat Model
The structured question of what can go wrong in a system, who would benefit, and what it would cost.
A threat model answers four questions: what are we building? What can go wrong with it? What are we doing about that? And did we do a good enough job? That sounds banal, but most security problems arise not from missing knowledge but from those questions never being asked explicitly.
The right moment is before implementation. At that point a change costs a discussion; after the build it costs a rebuild. So our projects start there - before frameworks are discussed, we settle where the trust boundaries run and which data crosses them.
The exercise becomes useful through specificity. "An attacker could steal data" helps nobody. "A user with a valid account can retrieve another customer invoice by manipulating the invoice ID" describes a case you can reproduce, fix, and test. The output is therefore not a risk matrix but a list of concrete scenarios, each with a decision behind it.
A threat model is also the cheapest security artefact a project can have. It needs no tooling and no certification - only the people involved for half a day, and someone to ask the uncomfortable questions.
The service behind it
Security & Infrastructure