Stride Threat Modeling

securityskills/skills/threat-modeling/stride-threat-modeling

by securityskillsb2b6b5200ee91a249816df209a0b89ff01ae450aNo licenseListed Oct 9, 2026Updated Oct 9, 2026

Run a STRIDE-based threat modeling workshop — diagram the system, enumerate threats per element, rank them, and drive mitigations into the backlog. Use during design reviews and new feature planning.

Instructions onlySecurity
AI-generated overview

Runs a STRIDE threat modeling workshop: diagram the system, enumerate and rank threats, and plan mitigations.

What it does
This skill guides a structured STRIDE threat modeling workshop. It walks through modeling a system with processes, data stores, flows, actors and trust boundaries, enumerating threats per element using the STRIDE categories, ranking them by impact and likelihood, and choosing mitigation strategies. It produces a system diagram with trust boundaries, an element-by-STRIDE threat grid, a ranked risk register, and mitigations mapped to tracked backlog tickets.
When to use it
Use it during design reviews and new feature planning, or whenever a system's architecture needs a systematic security threat assessment. It also fits re-reviewing a model after architecture changes such as new external dependencies, trust boundaries or data classes.
Requirements
No scripts or special tooling are required; it is an instructions-only skill. It needs a system or design to analyze and a place to record the diagram, threat grid, risk register and tickets.

STRIDE 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:

CategoryApplies ToQuestion
SpoofingProcesses, actorsCan someone pretend to be this? (auth)
TamperingFlows, storesCan data be modified in transit/at rest? (integrity)
RepudiationProcessesCan actions be denied? (logging/audit)
Information disclosureFlows, storesCan data leak to unauthorized parties? (confidentiality)
Denial of serviceProcesses, flowsCan this be exhausted or crashed? (availability)
Elevation of privilegeProcessesCan 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.

Source and attribution

Source:securityskills/skillsinthreat-modeling/stride-threat-modelingat commitb2b6b52

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal