Performs STRIDE threat modeling for features, APIs, and architecture changes, producing a threat model document with risk-rated threats, mitigations, and security stories ready for the backlog. Use during sprint planning or design review. Triggers on: "threat model", "STRIDE", "security risks of this feature", "what could go wrong with this design", "security review of architecture".
Performs STRIDE threat modeling for features, APIs, and architecture changes, producing a threat model document with risk-rated threats, mitigations, and security stories ready for the backlog. Use during sprint planning or design review. Triggers on: "threat model", "STRIDE", "security risks of this feature", "what could go wrong with this design", "security review of architecture".
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
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.
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.
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.
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.
Deliver the document using the template, and tell the user which stories should enter the next sprint.
STRIDE Categories
Category
Question to ask
Typical mitigations
Spoofing
Can someone pretend to be a user, service, or device?
Strong authentication, mTLS, signed tokens
Tampering
Can data be modified in transit or at rest?
TLS, integrity checks, signed payloads, immutable logs
Repudiation
Can an actor deny performing an action?
Audit logging with identity + timestamp, log integrity
AuthZ checks at every boundary, input validation, sandboxing
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.
