Threat Modeling
Threat modeling identifies assets, trust boundaries, attackers, and mitigations before code is written, turning security from a checklist into a design activity.
Definition
Threat modeling is a structured review of a system's assets, data flows, trust boundaries, and attacker capabilities. The team asks what can go wrong, what controls exist, and what residual risk remains. Common methods include STRIDE, attack trees, and data-flow diagrams. The output is a prioritized set of mitigations and assumptions, not a one-time document.
Context and scope
Threat modeling is used during design, before major features, and when architecture changes. It is most valuable when it includes engineers who understand the implementation and someone who can challenge assumptions.
Common misconceptions
- Threat modeling requires a security specialist — engineers can learn a lightweight method; specialists help with complex systems
- It is a one-time compliance artifact — threats change when data flows and dependencies change
- It only covers external attackers — insiders, compromised dependencies, and operator mistakes are also threats
Anti-patterns
- Producing a long document that nobody reads or updates
- Listing generic threats without mapping them to assets and boundaries
- Treating every risk as equally important instead of ranking by impact and likelihood
Related concepts
Related examples
Authoritative source
Draw the data flow first
A threat model starts with what the system does, not with a list of attacks. Draw users, services, data stores, external dependencies, and the trust boundaries between them. Mark where data crosses from a less trusted zone to a more trusted one. Authentication, authorization, encryption, and validation should be visible at each boundary.
Browser --HTTPS--> API gateway --mTLS--> Orders service --TLS--> PostgreSQL
| |
+-- third-party payment (untrusted) +-- event bus (internal)Ask structured questions
STRIDE is a useful checklist: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. For each boundary, ask which of these apply, what control exists, and what evidence shows the control works. Also consider supply chain, insiders, misconfiguration, and data retention. Rank risks by impact and likelihood, and assign an owner.
Turn findings into work
A threat model that does not change code or operations is documentation theater. Convert findings into tickets with acceptance criteria, add tests for the controls, and revisit the model when data flows or dependencies change. Record accepted risks with an owner and an expiry date.
When to use it
Use threat modeling before a new feature, a major integration, or an architecture change, and when a security incident reveals a blind spot. The advantage is finding design flaws before they are expensive; the drawback is time and the need for honest participation. Compared to a generic security checklist, threat modeling is specific to the system and produces prioritized work.