Threat modeling is structured worry: what are we building, what can go wrong, what will we do about it, and did we do a good job. Learn when to do it and the four-question frame that drives the rest.
Threat modeling is a design-time review that looks for security flaws in how a system is built — before any code exists to exploit. It is the cheapest place to catch an entire class of bug: a missing trust boundary found on a whiteboard costs a sticky note; the same flaw found in production costs an incident. As a DevSecOps engineer you drive this activity, not a separate security team.
Threat modeling answers four questions (Shostack's frame):
1. What are we building? -> a diagram of the system
2. What can go wrong? -> threats against that diagram
3. What are we going to do? -> a mitigation / control per threat
4. Did we do a good job? -> validate the model + the fixes
Everything else in this course is a technique for answering
one of those four questions well.Do a threat model when the design is fresh enough to change but concrete enough to reason about — a new service, a new trust boundary (a new third party, a new data store of sensitive data), or a major refactor. It is not a one-time gate: re-visit the model when the architecture shifts. In a DevSecOps flow it lives beside the design doc / ADR, and its output becomes backlog tickets and pipeline checks.
GOOD triggers to (re)model:
- new service or new external integration
- a new class of sensitive data enters the system (PII, payments, tokens)
- auth / trust boundary changes
- a big architecture change (monolith -> services, new queue, new cloud)
BAD time to start: after it shipped and broke.
Cheap to fix at design time; expensive to fix in prod.
Cadence: model the design, then keep it as a living doc — a
5-minute review each time the diagram changes beats a 3-day
audit once a year.Before you can say what can go wrong, name what is worth protecting (assets), who might come after it (adversaries), and every place they can interact with the system (attack surface). You do not need a perfect actor taxonomy — a few realistic adversaries with different capabilities is enough to shake out different threats.
ASSETS what an attacker wants / what hurts if lost
e.g. customer PII, password hashes, signing keys,
money movement, availability of checkout
ADVERSARIES who, and what they can do
external unauthenticated -> hits public endpoints
authenticated user -> abuses their own access
malicious insider -> has creds + knowledge
supply-chain attacker -> owns a dependency / CI
ATTACK every entry point where untrusted data/actor meets
SURFACE the system: HTTP endpoints, file uploads, webhooks,
admin panels, the CI/CD pipeline, cloud IAM.A threat model that produces a 40-page PDF nobody reads has failed. The deliverable is a short, living artifact plus a set of tracked decisions: mitigate, eliminate, transfer, or accept — each recorded with a rationale. Un-actioned threats are the point of the exercise, so they go straight into the same backlog as feature work.
For every threat you find, pick ONE and record it:
MITIGATE add a control (validation, authz check, rate limit)
ELIMINATE remove the feature / data that creates the risk
TRANSFER push risk elsewhere (managed service, insurance, WAF)
ACCEPT document why the risk is tolerable + who signed off
"Accept" is a valid answer — but it must be a written, owned
decision, not silence. Silent risk is the default failure mode.