Threat Modeling

Systematically reason about what can go wrong before code ships. STRIDE, attack trees, trust boundaries. The discipline that turns security from reactive to designed-in.

Ask ‘what could go wrong’ before shipping. List threats. Score them. Design mitigations. Iterate. Status: STUB — promoted to OUTLINE in Y2 Phase 12.

What this pattern is

Threat modeling is the structured discipline of asking “what can go wrong” before code ships. The canonical method is STRIDE (Microsoft, 1999): for each component, ask whether it’s vulnerable to Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, or Elevation of privilege. Attack trees decompose a goal an attacker has into the steps required to reach it. Trust boundaries mark where data crosses between zones of differing trust (user → API, API → DB, internal → external); every boundary is a place to validate.

The pattern is not about producing perfect security analysis; it’s about deliberate security thinking integrated into design. A 30-minute threat-modeling session on a new feature catches more issues than a 30-hour penetration test discovers after the feature ships. Threat models are cheap; production incidents are expensive. The math is easy; the discipline is what’s hard.

Senior engineers do this without prompting. When someone proposes a new integration, a new feature, or a new service, the senior engineer’s first questions are threat-model-shaped: “Who can call this? What can they do? What’s the worst thing they could do if they compromised the caller? What crosses trust boundaries?” Junior engineers ship first and react to breaches later. The gap is real and career-defining.

Every OSS launch during /root gets a threat model. Every phase that adds a new service to basecamp adds a threat-model section to the phase doc. The pattern accumulates as habit rather than as a separate audit step.

Concrete instances in the wild

  • STRIDE. Microsoft’s canonical threat-modeling framework. For each component in a design, ask about six threat classes (Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege). Simple, exhaustive-ish, teachable.
  • Attack trees. Decompose an attacker’s goal into steps. Root node is the goal (“exfiltrate customer PII”); children are the steps required; leaves are concrete vulnerabilities. Bruce Schneier’s canonical formulation.
  • Trust boundaries in data flow diagrams. Every DFD arrow that crosses a trust boundary is a place to validate. User input crossing into the app tier; app tier crossing into database; internal service crossing to external API.
  • LINDDUN. Privacy-focused threat modeling. Six privacy threat categories (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness).
  • PASTA (Process for Attack Simulation and Threat Analysis). More rigorous than STRIDE, aimed at enterprise risk. Seven-stage process from business objectives through countermeasures.
  • OWASP Threat Dragon. Open-source threat-modeling tool for drawing data flow diagrams and mapping STRIDE threats visually.
  • Adam Shostack’s four-question framework. Simpler than STRIDE: “What are we working on? What can go wrong? What are we going to do about it? Did we do a good job?”
  • Pre-mortems as threat models. Not strictly security-focused, but the same “imagine failure before shipping” pattern applied to project risk.
  • Bug bounty programs as continuous threat models. Programs like HackerOne turn external researchers into ongoing threat-model contributors, finding what internal analysis missed.

Why this pattern matters

Without threat modeling, security is retrospective. Code ships; something breaks or gets attacked; someone patches it. Repeat. Each incident is a surprise because nobody considered the failure mode before shipping. Post-incident, the mitigation is bolted on; the underlying design still has other similar failure modes waiting to be discovered.

With threat modeling, security is proactive. Design-time thinking surfaces the failure modes before the code exists. Mitigations get built in rather than bolted on. Trust boundaries get identified and instrumented. When the first incident happens (and it will), the threat model tells you whether it was expected or new, and the mitigation slots into existing structure rather than requiring a rewrite.

The pattern also produces institutional memory. Threat models are artifacts. A senior engineer can read a five-year-old threat model and understand what the team was defending against and why. When new engineers join, threat models teach them how the team thinks about risk. When compliance auditors ask “how do you know your system is secure?”, threat models are the answer — better than “we ran a scanner.”

The failure mode to avoid: threat modeling as ceremony. Producing a 40-page threat-modeling document once at the start of a project and never touching it again is worse than doing nothing (creates false confidence). Real threat modeling is continuous, lightweight, and integrated into design review. A 30-minute session per new feature, appended to the design doc, is more valuable than an annual “threat modeling week.”

Depth progression

STUB     ← you are here.
OUTLINE  Promoted when Y2 Phase 12 introduces STRIDE on a real /root service.
DEEP     Promoted after Y3 end — threat modeling routinely applied to each
         new basecamp tier, with at least one finding that prevented an
         actual issue post-deploy.

Preview: what OUTLINE will answer

When Y2 Phase 12 promotes this entry to OUTLINE, it will name:

  • PROBLEM. How do you find security issues in a design before the code exists to run against?
  • PRINCIPLES. Systematic decomposition (STRIDE, attack trees). Identify trust boundaries. Focus on attacker goals, not attack techniques. Iterate as design changes. Produce a written artifact.
  • TRADE-OFFS. Depth (STRIDE-per-component) vs breadth (attacker goal analysis). Formal (PASTA seven-stage) vs lightweight (Shostack four-question). Threat catalog approach (list known threats) vs risk analysis approach (score likelihood + impact). One-time (during design) vs continuous (each feature).
  • TOOLS (time-stamped as of 2026-06): STRIDE (Microsoft), attack trees (Schneier), LINDDUN (privacy), PASTA (enterprise), OWASP Threat Dragon (visual), Adam Shostack’s Elevation of Privilege card game (educational).

The DEEP promotion, after Y3 end with threat modeling routine, will add MASTERY (running threat models for every new tier for a year), COMPARE (STRIDE vs attack trees vs Shostack’s four questions), OPERATE (a specific finding from a threat model that prevented a real incident), and CONTRIBUTE (a threat-model contribution to an OSS project or a public blog post walking through one).

Canonical references

  • Adam Shostack, Threat Modeling: Designing for Security (2014) — the canonical modern text. Practical, walks through STRIDE with real examples.
  • Microsoft’s STRIDE documentation and threat-modeling tool. Free.
  • Bruce Schneier, Attack Trees — the original paper. Free at schneier.com.
  • OWASP Threat Modeling project and Threat Dragon tool — free open-source resources.
  • Loren Kohnfelder, Designing Secure Software — modern comprehensive treatment, includes AI/ML threat modeling.

Cross-references