---
name: threat-modeling
description: >-
  Identifies and prioritizes threats using STRIDE analysis on data flow diagrams.
  Use when designing new systems, adding major features, reviewing architecture
  for security risks, or documenting accepted risks. NOT for code-level scanning,
  active incident response, or compliance mapping.
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash
---

## Identity & Scope

**Executor:** either
**Model tier:** opus
**Scope:** Architecture diagrams, design docs, data flow descriptions, API specs, infrastructure configs, code structure.
**Off-limits:** Exploiting threats, modifying production, making risk acceptance decisions (user's job).

### Hard Rules
- No credentials in output or git — ever
- No spending money or publishing without explicit user approval
- No deleting files — archive first, 48hr hold
- Report completion to boss via structured output

## Essential Principles

1. **Draw data flow first** — Users, services, stores, trust boundaries before threats. Guards against: ad-hoc analysis missing components.
2. **Apply STRIDE to every component** — All 6 categories per component, not just obvious ones. Guards against: tunnel vision.
3. **Rate by likelihood AND impact** — Different combinations rank differently. Guards against: treating all threats as equal.
4. **Document accepted risks** — Unmitigated risks need justification on record. Guards against: invisible technical debt.
5. **Propose specific mitigations** — "Add JWT with RS256 at gateway" not "implement auth." Guards against: unactionable advice.

## When to Use
- Designing a new system or service
- Major feature changing data flows or trust boundaries
- "What could go wrong with this architecture?"
- Pre-launch security review of system design

## When NOT to Use
- Code-level vulnerability scanning — use security-assessment instead
- Active incident — use incident-response instead
- Compliance framework mapping — use compliance-mapping instead
- Penetration testing — use dedicated pentest skills

## Rationalizations to Reject

| Shortcut | Why it's wrong |
|----------|----------------|
| "Skip the DFD, go straight to threats" | Without a DFD you'll miss components and boundaries. |
| "STRIDE is overkill for a simple service" | Even simple services have 6 threat categories. |
| "Internal services don't need modeling" | Internal services are top lateral movement targets. |
| "Accepted risks don't need docs" | Undocumented accepted risks are invisible risks. |

## Workflow

### Phase 1: Data Flow
**Entry:** System architecture provided or inferable from code.
**Actions:**
1. Identify actors (users, admins, external/internal services, jobs).
2. Identify data stores (DBs, caches, files, queues, secrets).
3. Map data flows between actors, services, stores.
4. Draw trust boundaries. Identify all external entry points.
**Exit:** Data flow diagram with actors, services, stores, flows, boundaries.

### Phase 2: STRIDE Analysis
**Entry:** Phase 1 complete.
**Actions:**
1. For each component and boundary crossing, check all 6 STRIDE categories:
   **S**poofing | **T**ampering | **R**epudiation | **I**nfo Disclosure | **D**oS | **E**levation of Privilege.
2. Document each threat: component, STRIDE category, description, attack scenario.
3. Mark "N/A" with reason where a category doesn't apply.
**Exit:** Complete threat inventory with STRIDE categorization.

### Phase 3: Rate & Mitigate
**Entry:** Phase 2 complete.
**Actions:**
1. Rate each threat: likelihood (L/M/H) x impact (L/M/H).
2. Propose specific mitigations for high/critical risks.
3. Document threats for potential acceptance with justification.
**Exit:** All threats rated, mitigations for high/critical, accepted risks documented.

### Phase 4: Verify
**Entry:** All prior phases complete.
**Actions:**
1. Confirm every component analyzed against all 6 STRIDE categories.
2. Confirm every threat has likelihood, impact, and risk rating.
3. Confirm high/critical threats have specific mitigations.
4. Confirm accepted risks documented with justification.
**Exit:** All checks pass — report results to boss/user.

## Output Format

```json
{
  "skill": "threat-modeling",
  "status": "completed",
  "worker": "worker-007",
  "summary": "5 components, 3 trust boundaries. 18 threats: 2 critical, 5 high, 7 medium, 4 low.",
  "findings": [
    {"item": "JWT theft via XSS enables account takeover", "severity": "critical", "detail": "Spoofing @ Auth API. JWTs in localStorage accessible via XSS.", "stride": "Spoofing", "component": "Auth API", "likelihood": "high", "impact": "critical", "mitigation": "httpOnly cookies, SameSite=Strict, 15min TTL with refresh rotation."},
    {"item": "No audit log on admin actions", "severity": "medium", "detail": "Repudiation @ Admin Panel. No trail for admin writes.", "stride": "Repudiation", "component": "Admin Panel", "likelihood": "medium", "impact": "high", "mitigation": "Immutable audit log: actor, action, target, timestamp, previous value."}
  ],
  "data_flow": {
    "actors": ["End User", "Admin", "Payment Processor"],
    "services": ["Web App", "Auth API", "Order Service"],
    "stores": ["User DB", "Order DB", "Redis"],
    "trust_boundaries": ["Public <-> Web App", "Web App <-> Services", "Services <-> DB"]
  },
  "accepted_risks": [{"threat": "DDoS on public endpoints", "justification": "CDN rate limiting mitigates. Full protection exceeds budget."}],
  "errors": [],
  "elapsed_seconds": 98.5
}
```

**Bad example:** `{"summary": "Did a threat model", "findings": [{"item": "Auth issues", "detail": "Could be better."}]}` — No STRIDE, no component, no DFD, no ratings, no mitigations. "Could be better" is not a threat.

## Escalation Triggers

STOP and report to boss when:
- System has no authentication/authorization layer at all
- Sensitive data (PII, financial, medical) processed with no encryption
- System is fundamentally insecure by design (not fixable with mitigations)
- Missing infrastructure/network diagrams needed for analysis
- Analysis reveals potential regulatory violations

Report as: `{"status": "escalated", "reason": "...", "context": "...", "recommendation": "..."}`

## Success Criteria

- [ ] Data flow diagram with actors, services, stores, trust boundaries
- [ ] Every component analyzed against all 6 STRIDE categories
- [ ] Every threat has likelihood, impact, risk rating
- [ ] High/critical threats have specific mitigations
- [ ] Accepted risks documented with justification
- [ ] Output matches JSON format above
