Threat modeling is the structured practice of examining a system's design to answer one question before attackers do: what can go wrong here, and what are we going to do about it? Instead of waiting for a scanner to flag a bug in shipped code, threat modeling works on the whiteboard — analyzing how data flows, where trust boundaries sit, and which assets an adversary would target — so that defenses are designed in rather than bolted on. It is the single highest-leverage security activity available to a team, because a threat caught in a design review costs a conversation to fix, while the same threat caught in production costs an incident.
Why It Matters
Most vulnerabilities are not clever zero-days; they are predictable consequences of design decisions nobody scrutinized. An unauthenticated internal endpoint, a queue that trusts any message, a token that never expires — these are design flaws, and no amount of code-level scanning reliably catches a missing security requirement. You cannot scan for a control that was never specified.
Threat modeling matters because it shifts security to the earliest and cheapest point in the lifecycle. The economics are stark: remediating a design flaw after release routinely costs an order of magnitude more than addressing it during design, because the fix now touches shipped data, live integrations, and customer contracts. It also matters for compliance — frameworks including SOC 2, ISO 27001, and the NIST Secure Software Development Framework (SSDF) now expect evidence that teams consider threats during design, not just that they scan afterward. This is precisely why devsecops threat modeling gets treated as a pipeline gate rather than a one-off workshop in mature programs: it's the design-time counterpart to the scanning and testing that happens later in CI.
How to Do It: The Four-Question Framework
The most durable model, popularized by Adam Shostack, reduces threat modeling to four questions. You do not need heavyweight tooling to start — a diagram and a room work fine.
- What are we building? Draw the system. A data flow diagram showing processes, data stores, external actors, and the trust boundaries between them is enough. If you cannot draw it, you do not understand it well enough to secure it.
- What can go wrong? Walk each element and enumerate threats. A mnemonic like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) keeps the brainstorm systematic instead of relying on whoever in the room is most paranoid.
- What are we going to do about it? For each credible threat, decide: mitigate (add a control), eliminate (remove the feature), transfer (push the risk elsewhere), or accept (document and move on).
- Did we do a good job? Review the model against the built system. Threat models are living documents, not one-time deliverables.
A lightweight session output — a threat modeling example you can adapt directly — looks like this:
| Element | Threat (STRIDE) | Decision | Control |
|---|---|---|---|
| Login API | Spoofing | Mitigate | MFA + rate limiting |
| Audit log | Repudiation | Mitigate | Append-only, signed entries |
| Payment queue | Tampering | Mitigate | Message signature verification |
| Admin export | Information disclosure | Mitigate | Field-level authorization |
The flow through a session is simply: scope → diagram → enumerate → decide → track. Each tracked decision becomes a security requirement or a ticket, which is what turns a modeling session into shipped protection rather than a slide deck.
Common Pitfalls
- Boiling the ocean. Trying to model an entire platform at once produces a diagram nobody can reason about. Scope to one feature, service, or trust boundary per session.
- Treating it as a one-time gate. A threat model created at kickoff and never revisited is stale within a sprint. Re-model when trust boundaries change — a new integration, a new data class, a new external actor.
- No follow-through. The most common failure is generating a great list of threats that never become tickets. If a session does not produce tracked, owned action items, it did not happen.
- Security-team-only sessions. The engineers who built the system know where the bodies are buried. Threat modeling done to a team instead of with it misses the real design assumptions.
- Perfectionism about the diagram. A rough, correct diagram beats a beautiful, aspirational one. Model the system as it is.
How It Connects to Supply Chain Security
Classic threat modeling assumed you owned most of the code you ran. In 2026 that assumption is gone: the majority of a modern application is third-party open source, pulled through build systems, package registries, and container layers you do not control. That means the threat model has to include the supply chain as a first-class actor. "What can go wrong?" now includes a compromised dependency, a typosquatted package, a poisoned build step, or a malicious maintainer — exactly the pattern behind incidents like the xz-utils backdoor.
When you extend the four questions to the supply chain, the "what are we building" diagram must show where external code enters, and the "what can go wrong" step must treat every dependency edge as a trust boundary. This is where tooling closes the loop. Software Composition Analysis inventories the open source components a threat model has to account for, turning "we depend on stuff" into a concrete list of trust relationships. Dynamic testing validates that the mitigations you designed actually hold against a running system. And because a modern threat model produces more findings than any human can triage, Griffin AI correlates and prioritizes them so the design-time threats you identified map to the real, reachable risks in your deployed code. For the wider vocabulary of secure design, our concepts library connects threat modeling to the principles it depends on.
Safeguard's role is to make a threat model actionable rather than aspirational: the trust boundaries you draw on the whiteboard become the components, pipelines, and endpoints we continuously monitor, so a design decision made in July is still enforced in December.
Create a free account to connect your repositories, or read the documentation to see how design-time threats map to continuous monitoring.
Frequently Asked Questions
When should we start threat modeling a project?
As early as you have a design worth drawing — ideally before a line of code is written, during the design or architecture phase. The whole value is catching flaws while they are cheap to fix. That said, it is never too late; modeling an existing system almost always surfaces controls that were assumed but never actually built.
Do we need special tools to threat model?
No. The most effective threat models start with a whiteboard, a data flow diagram, and a mnemonic like STRIDE. Dedicated tools help scale the practice across many teams and keep models version-controlled, but tooling is an accelerator, not a prerequisite. Starting with paper is far better than not starting.
Who should be in a threat modeling session?
The people who built or are building the system, at minimum — usually engineers and a tech lead — plus someone who can facilitate the security thinking. Product can clarify what data matters. Keep it small enough that everyone talks; five or six people is plenty.
How is threat modeling different from a penetration test?
Threat modeling is proactive and design-focused: it reasons about what could go wrong before or alongside building. A penetration test is reactive and implementation-focused: it attacks a running system to find what did go wrong. They are complementary — a threat model tells the pen tester where to look, and the pen test validates whether your modeled mitigations actually work.