Threat Model Builder

---
name: threat-model-builder
description: Use when analyzing a system or feature design for security threats before implementation. Triggers on "threat model", "STRIDE", "attack surface", "trust boundary", "security review", "pre-ship security check", or architecture descriptions that touch auth, payments, or external integrations.
---

# Threat Model Builder

Security review after implementation finds bugs. Threat modeling before implementation prevents architecturally-baked-in vulnerabilities — the kind that can't be patched, only redesigned. STRIDE is the framework: six threat categories, applied systematically to every data flow.

## Required inputs

Before producing a threat model, confirm you have:

1. **System or feature description** — what it does, who uses it, what data it handles
2. **Data flow** — even rough: which actors send/receive data, which services call which, where data is stored
3. **Trust boundaries** — the lines that separate different trust levels (user → app, app → database, app → third-party API)
4. **Existing security controls** — what's already in place (auth system, existing encryption, network controls)

If you only have a vague description, ask for the data flow before modeling. A threat model without a data flow is guesswork.

## Method

### Step 1: Map actors, assets, and trust boundaries

- **Actors**: who interacts with the system (end user, admin, third-party service, internal service)
- **Assets**: what's worth protecting (user PII, auth tokens, payment data, session state)
- **Trust boundaries**: draw a line between every pair of zones that don't inherently trust each other (internet → app, app → database, app → external API, user → admin UI)

### Step 2: Enumerate entry points

Every place where data crosses a trust boundary is an entry point:
- API endpoints (public and internal)
- Webhooks and callbacks
- File uploads
- OAuth redirects / callbacks
- Browser-to-server requests (form posts, fetch calls)
- Background job triggers

### Step 3: Apply STRIDE to each entry point

For each entry point, work through all six categories. Not every category applies everywhere — but check each one and document why you're skipping:

| Category | Threat question | Example |
|---|---|---|
| **S**poofing | Can an attacker impersonate a legitimate actor? | Forged JWT, stolen OAuth token |
| **T**ampering | Can data be modified in transit or at rest without detection? | Parameter injection, insecure direct object reference |
| **R**epudiation | Can an actor deny performing an action? | No audit log, unsigned webhook payloads |
| **I**nformation Disclosure | Can an attacker access data they shouldn't? | Verbose error messages, broken access control |
| **D**enial of Service | Can an attacker exhaust resources or block legitimate users? | No rate limiting, large payload handling, auth amplification |
| **E**levation of Privilege | Can an attacker gain permissions beyond their grant? | Mass assignment, role confusion, missing authorization checks |

### Step 4: Rate and prioritize each threat

For each identified threat:
- **Likelihood**: low / medium / high (is this exploitable in your deployment context?)
- **Impact**: low / medium / high (what breaks if it's exploited?)
- **Priority**: Likelihood × Impact (address High × High this sprint; Medium × Medium this quarter)

### Step 5: Recommend mitigations

One concrete mitigation per threat — not generic advice ("validate inputs"), but specific controls for this system:
- "Add HMAC signature verification on the `/webhook/slack` endpoint before processing the payload"
- "Scope the service account token to read-only on the `orders` collection; remove write permission"
- "Add rate limiting at the API gateway: 10 requests/second per IP on `/api/auth/login`"

## Output format

```markdown
## Threat Model: [Feature/System Name]

**Scope**: [one sentence — what's in and out of scope]
**Data flow summary**: [2-3 sentences or a list of the main flows]
**Trust boundaries identified**: [bulleted list]

### Entry points
[List of all data-crossing points]

### Threat table

| Entry Point | STRIDE Category | Threat | Likelihood | Impact | Priority | Mitigation |
|---|---|---|---|---|---|---|
| POST /api/auth/login | Spoofing | Credential stuffing — no rate limit | High | High | P0 | Rate limit: 10/min/IP; add CAPTCHA after 5 failures |

### Top 3 risks (if prioritizing is the ask)
[Ranked by Priority, with one paragraph each explaining the risk and the fix]

### What's out of scope
[What this model didn't cover and why]
```

## Anti-patterns

- Treating the threat table as a compliance artifact to file, not a live document to act on
- Only modeling the happy path — threats live in error flows, retries, and edge cases
- Flagging every theoretical STRIDE threat without triage — an unranked list of 40 threats is noise
- Generic mitigations ("use encryption") instead of specific controls ("use AES-256-GCM for the session token stored in Redis; rotate every 24h")
- Skipping Repudiation because "we have logs" — logging the wrong fields, or logs the attacker can delete, is not repudiation protection

## Scope this skill correctly

This is architectural threat modeling — what to design, what controls to build in. It is not:
- A penetration test (that requires active exploitation)
- A code review (use code-review-helper for that)
- A dependency scan (use dependency-and-cve-auditor for that)

If the user asks for all three, start here and hand off to the others after.