Applies STRIDE threat modeling to a feature or system design and produces a prioritized threat table with concrete mitigations ranked by exploitability and impact. Use when someone asks "threat model this feature", "what could go wrong with this design", "is this integration safe to build", or is reviewing auth flows, new data stores, webhook receivers, file uploads, or external integrations before the code is written. Do NOT use for prioritizing scanner or pentest findings on already-shipped code - use vulnerability-triage instead; for line-by-line security review of written code, use secure-code-review.
Click to play with sound.
---
name: Threat Model STRIDE
description: Applies STRIDE threat modeling to a feature or system design and produces a prioritized threat table with concrete mitigations ranked by exploitability and impact. Use when someone asks "threat model this feature", "what could go wrong with this design", "is this integration safe to build", or is reviewing auth flows, new data stores, webhook receivers, file uploads, or external integrations before the code is written. Do NOT use for prioritizing scanner or pentest findings on already-shipped code - use vulnerability-triage instead; for line-by-line security review of written code, use secure-code-review.
---
# Threat Model STRIDE
A threat found at design review costs a paragraph in a doc; the same threat found in production costs an incident, a credential rotation, and sometimes a disclosure. STRIDE catches whole classes of flaws - spoofed callers, tamperable payloads, privilege leaks - before there is code to review. Apply it to any feature touching auth, data storage, external calls, or privilege changes; skip it and the same flaws surface later in secure-code-review or, worse, in vulnerability-triage.
## Operating procedure
Follow the steps in order. Threats enumerated before trust boundaries are explicit come out vague and unactionable, and mitigations written before scoring waste effort on Low findings.
### Step 1: Gather inputs
Collect these before modeling. Where the user cannot answer, use the default and label the assumption a guess.
- Feature description in 3-5 sentences: what it does, who calls it, what it stores.
- Actors: users, internal services, external APIs, admin roles. Default: anonymous internet user, authenticated user, one backend service.
- Data assets and a sensitivity tier for each: credentials > financial > PII > internal > public.
- Deployment context: internet-facing or internal-only; behind a WAF or VPN or not.
- Existing controls: auth mechanism (session, JWT, mTLS), rate limiting, audit logging.
- Compliance regime in scope (SOC 2, PCI, HIPAA, GDPR), if any.
### Step 2: Map the data flow in prose… load the full skill through Skill Me