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
- 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 |
| Information disclosure |
Can data leak to the wrong party? |
Encryption, least-privilege access, output filtering, masking |
| Denial of service |
Can the component be made unavailable? |
Rate limiting, quotas, timeouts, autoscaling, circuit breakers |
| Elevation of privilege |
Can a user gain rights they shouldn't have? |
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.
1---2name: threat-modeling3description: 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".4license: MIT5---67# Threat Modeling (STRIDE)89Produce 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.1011## Process12131. **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.142. **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.153. **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.164. **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.175. **Deliver the document** using the template, and tell the user which stories should enter the next sprint.1819## STRIDE Categories2021| Category | Question to ask | Typical mitigations |22|----------|-----------------|---------------------|23| Spoofing | Can someone pretend to be a user, service, or device? | Strong authentication, mTLS, signed tokens |24| Tampering | Can data be modified in transit or at rest? | TLS, integrity checks, signed payloads, immutable logs |25| Repudiation | Can an actor deny performing an action? | Audit logging with identity + timestamp, log integrity |26| Information disclosure | Can data leak to the wrong party? | Encryption, least-privilege access, output filtering, masking |27| Denial of service | Can the component be made unavailable? | Rate limiting, quotas, timeouts, autoscaling, circuit breakers |28| Elevation of privilege | Can a user gain rights they shouldn't have? | AuthZ checks at every boundary, input validation, sandboxing |2930## Threat Model Template3132```markdown33# Threat Model: [Feature Name]34**Date:** [YYYY-MM-DD] · **Sprint/Milestone:** [if applicable] · **Participants:** [names/roles]3536## Feature Description37[2-3 sentences: what it does and what data it touches]3839## Data Flow40[User → Frontend || API Gateway → Service → Database]41(|| marks trust boundary crossings)4243## STRIDE Analysis44| # | Threat | Category | Likelihood | Impact | Risk | Mitigation |45|---|--------|----------|-----------|--------|------|------------|46| 1 | [description] | [S/T/R/I/D/E] | H/M/L | H/M/L | H/M/L | [concrete control] |4748## Security Stories Generated49- [ ] [Story title] — [priority] — [estimate if known]5051## Residual Risks (accepted)52- [Low-risk threat] — [one-line justification for accepting]53```5455## Security Story Format5657```markdown58**As** [the system/security role], **I want** [security control], **so that** [risk is mitigated].59**Threat:** [STRIDE category + threat #] · **Source:** threat model [feature name]60**Acceptance:** Given [precondition], when [attack vector attempted], then [system prevents/detects/alerts].61```6263## Guidelines6465- 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.66- Prefer mitigations that already exist in the team's stack (their gateway, their IdP) over introducing new components.67- 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.68- 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.
timwukp