Chapter 1 · Practice 2 of 4
Threat model during design, then again as the design changes
Why it matters
The Manifesto's first principle is that the best use of threat modeling is to improve the security and privacy of a system through early and frequent analysis. The OWASP cheat sheet says the same: do it early, ideally during design, and treat the model as a living artifact, not something performed once and never again.
Early matters because the cheapest fixes are design changes: moving a check to the server, splitting a service account, dropping a data field you do not need. After release, the same fix can mean a migration and a deprecation.
Frequent matters because systems change. The Manifesto says threat modeling should follow design changes in iterations, each scoped to a manageable portion of the system. A model of last year's architecture is mostly a record of what you used to worry about.
Good moments to threat model:
- a design doc or RFC for a new feature or service
- a new external integration, data store or third-party API
- a change to authentication, authorization or who can reach an endpoint
- handling a new kind of sensitive data (payments, health, children's data)
- adding an LLM or agent that reads untrusted input or calls tools
- after a security incident or a significant bug report in the area
Do
- Add a threat model section to your design doc template
- Revisit the model when a trigger in the list above happens
- Scope each session to one feature or flow
Avoid
- A single model of the whole platform, written once
- Threat modeling only after the code is merged