Threat Modeling (STRIDE)

Produce a lightweight, sprint-compatible threat model: 15-30 minutes of structured analysis, not a multi-week security assessment. The output is a threat model document plus security stories the team can schedule.

Process

1. Establish the data flow. Ask for (or derive from the code/design) the feature's data flow: actors, entry points, services, data stores, and trust boundaries. Summarize it as Actor → Component → ... → Store, marking each trust boundary crossing with ||. If the user has architecture docs or code, read them instead of asking.
2. Walk the STRIDE categories against each trust boundary crossing (see table below). For each plausible threat, capture: description, category, likelihood (H/M/L), impact (H/M/L), and a concrete mitigation. Skip categories that genuinely don't apply — do not pad the table.
3. Rate risk as High if likelihood or impact is High and the other is at least Medium; Low only if both are Low; otherwise Medium.
4. Generate security stories for every High and Medium threat using the story format below (or hand off to the security-story-writing skill if it is available). Low threats go to the residual risk list with a one-line acceptance rationale.
5. Deliver the document using the template, and tell the user which stories should enter the next sprint.

STRIDE Categories

Threat Model Template

# Threat Model: [Feature Name]
**Date:** [YYYY-MM-DD] · **Sprint/Milestone:** [if applicable] · **Participants:** [names/roles]

## Feature Description
[2-3 sentences: what it does and what data it touches]

## Data Flow
[User → Frontend || API Gateway → Service → Database]
(|| marks trust boundary crossings)

## STRIDE Analysis
| # | Threat | Category | Likelihood | Impact | Risk | Mitigation |
|---|--------|----------|-----------|--------|------|------------|
| 1 | [description] | [S/T/R/I/D/E] | H/M/L | H/M/L | H/M/L | [concrete control] |

## Security Stories Generated
- [ ] [Story title] — [priority] — [estimate if known]

## Residual Risks (accepted)
- [Low-risk threat] — [one-line justification for accepting]

Security Story Format

**As** [the system/security role], **I want** [security control], **so that** [risk is mitigated].
**Threat:** [STRIDE category + threat #] · **Source:** threat model [feature name]
**Acceptance:** Given [precondition], when [attack vector attempted], then [system prevents/detects/alerts].

Guidelines

• Anchor every threat to a specific element of the data flow — "hackers could attack the API" is not a threat; "an unauthenticated caller can enumerate user IDs via GET /users/{id} (Information disclosure)" is.
• Prefer mitigations that already exist in the team's stack (their gateway, their IdP) over introducing new components.
• If the feature touches payment card data, personal data, or runs in a regulated industry, recommend a compliance pass (e.g. the fsi-compliance-checker skill for financial services) in addition to the threat model.
• For a brand-new system rather than a feature, model the 2-3 most critical flows first rather than attempting full coverage in one session.