About stride-threat-modeling
stride-threat-modeling is a workshop-style skill for structuring system threat modeling. It guides security teams from diagramming trust boundaries through STRIDE enumeration, risk ranking, mitigation tracking, and validation.
Key features
- 01System diagram with trust boundaries
- 02Element-by-category STRIDE review
- 03Impact and likelihood risk ranking
- 04Mitigations linked to backlog tickets
- 05Architecture-change and incident review
Use cases
- 01Modeling a system during a security workshop
- 02Prioritizing threats across system components
- 03Turning accepted risks into tracked work
- 04Updating models after architecture changes
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/stride-threat-modelingin Claude Code to confirm it loaded.
Details
From the project READMESTRIDE Threat Modeling
Threat model a system in a structured workshop format.
1. Model the System
Draw the diagram: processes, data stores, data flows, external actors, and trust boundaries (dashed lines where privilege/context changes).
- Every element numbered; technologies noted on processes/stores
- Include the boring parts: auth flows, async jobs, admin tooling, backups
2. Enumerate with STRIDE
For each element, apply the applicable categories:
| Category | Applies To | Question |
|---|---|---|
| Spoofing | Processes, actors | Can someone pretend to be this? (auth) |
| Tampering | Flows, stores | Can data be modified in transit/at rest? (integrity) |
| Repudiation | Processes | Can actions be denied? (logging/audit) |
| Information disclosure | Flows, stores | Can data leak to unauthorized parties? (confidentiality) |
| Denial of service | Processes, flows | Can this be exhausted or crashed? (availability) |
| Elevation of privilege | Processes | Can rights be gained? (authz) |
Work systematically: element × category grid so nothing is skipped.
3. Rank
Score each threat by impact (worst realistic outcome) × likelihood (attack complexity, exposure). Prioritize: unauthenticated remote > authenticated remote > local > physical.
4. Mitigate
For each accepted threat, pick a strategy: reduce (control), transfer, accept (documented, with owner), or avoid (design change). Map mitigations to concrete backlog tickets with acceptance criteria.
5. Validate
- Review the model when the architecture changes (trigger: new external dependency, new trust boundary, new data class)
- Retro: incidents found in prod vs threats previously modeled — feed misses back into the method
Output
System diagram with trust boundaries, element × STRIDE threat grid, ranked risk register, and mitigations as tracked tickets.