/threat-modeling

name: threat-modeling
description: "Run a structured threat-modeling session for a new feature, system, or architecture — STRIDE, attack trees, data flow diagrams, abuse cases. Use when the user mentions 'threat model,' 'threat modeling,' 'STRIDE,' 'attack tree,' 'abuse case,' 'data flow diagram,' 'DFD,' 'security architecture review,' 'security review,' 'design review,' 'pre-implementation security,' 'shift left,' 'what could go wrong,' or needs strategic security thinking before code is written."
allowed-tools: Read, Write, Grep, Glob, WebSearch

Threat Modeling — Pre-Implementation Security Design

Run a structured threat-modeling session against a proposed feature, system, or architecture. This is the *design-time* security skill — different from audit (which inspects code that exists). Use this when there's a design doc, a feature spec, an architecture diagram — but not yet code.

When to use:

• New feature touching auth, payments, multi-tenant data, or sensitive PII
• New external integration (third-party API, OAuth provider, webhook receiver)
• New service / microservice being added to the architecture
• Significant refactor of a security-sensitive component
• Before committing to a major architecture decision (event-driven vs request/response, monolith split, AI-feature introduction)

Cross-references: `owasp-audit` (code-level checklist that lines up with the threats this surfaces), `api-audit` (API-specific category mapping), `iam-audit` (identity decisions touch every threat model).

The four questions

Adam Shostack's framing — every threat model answers these four:

1. **What are we working on?** (Scope and model) 2. **What can go wrong?** (Threats) 3. **What are we going to do about it?** (Mitigations) 4. **Did we do a good job?** (Validation)

The rest of this skill walks through each in order.

Step 1 — What are we working on?

Produce a Data Flow Diagram (DFD) at one of three levels:

• **Level 0** — Context diagram. One bubble for the system, lines to every external entity (users, third-party APIs, internal admin tools). Use this when the question is "what does this system even touch?"
• **Level 1** — Major processes. Auth service, API gateway, primary data store, payment integration, etc. Use this for most feature-level threat models.
• **Level 2** — Detailed component model. Specific endpoints, specific tables, specific queues. Use this for the trickiest parts only.

A useful DFD has:

• **External entities** (rectangles) — users, third-party services, admins
• **Processes** (circles) — your services, functions, handlers
• **Data stores** (parallel lines / cylinders) — databases, caches, blob storage, queues
• **Data flows** (arrows, labeled with what crosses) — request bodies, tokens, files, events
• **Trust boundaries** (dashed lines) — every crossing is a place data is validated, authenticated, or filtered

Trust boundaries are the most useful element. If you can draw exactly one diagram that shows every trust boundary in your feature, you've already done 60% of the work.

For text-only environments, render the DFD in Mermaid:

flowchart LR
  User[User] -- HTTPS --> WAF[WAF / CDN]
  WAF -- request --> API[API Gateway]
  API -- JWT --> Service[Service]
  Service -- SQL --> DB[(Postgres)]
  Service -- HTTPS --> Stripe[Stripe]

  classDef trust fill:#fff,stroke:#f00,stroke-dasharray:4 4
  class API,Service trust

Step 2 — What can go wrong? (STRIDE)

For each process, data store, and data flow, ask STRIDE — one threat category per letter. Not every category applies to every element, and that's fine.

| Letter | Threat | Property violated | Examples | |---|---|---|---| | **S** | **Spoofing** | Authentication | Stolen token, forged JWT, replay attack, impersonating a service | | **T** | **Tampering** | Integrity | Modifying a request mid-flight, parameter tampering, modifying stored data | | **R** | **Repudiation** | Non-repudiation | User denies an action; logs don't prove they did it | | **I** | **Information Disclosure** | Confidentiality | Leak via error messages, IDOR exposing other users' data, exposed S3 bucket | | **D** | **Denial of Service** | Availability | Resource exhaustion, expensive query bomb, billing exhaustion via paid downstream APIs | | **E** | **Elevation of Privilege** | Authorization | User → admin via mass assignment, BFLA, escape from sandbox |

STRIDE per element

A useful threat-modeling habit: for each element of the DFD, write a short table.

**Element:** API Gateway

| STRIDE | Threat | Likelihood | Impact |
|---|---|---|---|
| S | Forged JWT — symmetric secret in env, leaks if .env exposed | M | H |
| T | Request body modified between gateway and upstream service | L | M |
| R | Gateway access logs deleted by attacker post-breach | L | H |
| I | Verbose error responses expose internal hostnames | M | L |
| D | No rate limit at the gateway → upstream services overwhelmed | H | H |
| E | "X-Admin: true" header pass-through from external requests | L | C |

Likelihood and impact: L / M / H / C(ritical) — qualitative is fine; quantitative scoring is theater for most engagements.

Abuse cases (sister to STRIDE)

For features with business-flow concerns, also walk abuse cases. The format is:

As a malicious actor, I want to [goal] so that I can [outcome].

Examples:

• As a malicious customer, I want to redeem the same coupon code 100 times so that I can drain the discount budget
• As a competitor, I want to scrape every product detail in bulk so that I can clone your catalog
• As an insider with read access, I want to extract every customer's PII over a year so that I can sell it without triggering DLP alerts

Abuse cases catch what STRIDE misses — STRIDE is great at "security properties violated"; abuse cases are great at "business intent violated."

Step 3 — What are we going to do about it?

For each threat surfaced in Step 2, pick one of four responses:

• **Mitigate** — de