Threat Modeling
A structured exercise to find what could go wrong in a system before you build it — asking what you're protecting, who might attack it, and how, so you design defenses in.
What is threat modeling?
Threat modeling is a structured process for identifying, analyzing, and prioritizing potential security threats to a system before they can be exploited — ideally during design, not after a breach. Instead of bolting security on at the end, you sit down and reason systematically about what could go wrong: what you’re building, what could attack it, and what you’ll do about it. It shifts security “left” — earlier in the development lifecycle, where fixing a design flaw is vastly cheaper than fixing it in production or cleaning up after an incident.
The four questions at its core
Most threat modeling, regardless of methodology, boils down to four questions popularized by Adam Shostack: “What are we building?” (understand the system — data flows, components, trust boundaries, where data enters and leaves), “What can go wrong?” (enumerate threats against that model), “What are we going to do about it?” (decide on mitigations for the threats that matter), and “Did we do a good job?” (validate and iterate). Formal frameworks slot into this. STRIDE (Microsoft) is the most common threat-enumeration aid — a checklist of six categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — walked through against each component so you don’t just brainstorm threats ad hoc but cover the categories systematically. DREAD and PASTA offer alternative scoring/risk approaches; attack trees map how an attacker might reach a goal step by step. The specific method matters less than doing the exercise structured rather than by gut feel.
Why it’s worth doing — and how it goes wrong
The value is finding design-level flaws early: an architecture that trusts the wrong boundary, a data flow that exposes secrets, a missing authentication check — the kind of structural problem that a code review or a scanner won’t catch because it’s about the design, not a line of code. Catching these on a whiteboard is orders of magnitude cheaper than after they ship. Threat modeling is a core practice in DevSecOps and secure-by-design programs, and it pairs naturally with other controls: it tells you where to focus penetration testing, code review, and monitoring. Where it fails in practice: teams do it once and never revisit it (systems evolve, so threat models must be living documents updated as architecture changes); they make it a heavyweight, document-for-its-own-sake ritual that developers resent and skip (lightweight, frequent, developer-led modeling beats an exhaustive annual report nobody reads); or they enumerate threats but never actually track the mitigations to completion, so the analysis produces a list that gathers dust. The point isn’t the document — it’s changing what you build.
What people get wrong
- Doing it once and forgetting it — systems change, so a stale threat model quickly stops reflecting real risk; keep it living.
- Making it too heavyweight: an exhaustive, ceremony-laden process gets skipped; lightweight, frequent, developer-owned modeling actually gets done.
- Not closing the loop — enumerating threats without tracking mitigations to done produces a checklist, not improved security.
Primary source: OWASP Threat Modeling
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.