Threat Modeling

by bobmatnyc718070a7d622MIT77 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 2 months ago

Threat modeling workflow for software systems: scope, data flow diagrams, STRIDE analysis, risk scoring, and turning mitigations into backlog and tests. Use when designing new features, reviewing architecture changes, handling sensitive data, or hardening auth/payment/multi-tenant flows.

Instructions onlySecurity
AI-generated overview

Runs a lightweight STRIDE threat modeling workshop and turns identified risks into mitigations, tickets, and tests.

What it does
Guides a six-step threat modeling workflow: scoping the system and assets, drawing data flow diagrams with trust boundaries, applying STRIDE per element, scoring impact and likelihood, and converting prioritized threats into mitigations. It produces a data flow diagram, a threat register, and a mitigation plan expressed as backlog tickets, abuse-case tests, and PR checklist items. Reference files provide a workshop agenda, a threat catalog, and copy/paste templates.
When to use it
Use when designing new features, reviewing architecture changes, handling sensitive data, or hardening authentication, payment, and multi-tenant flows. It fits teams that want a structured security review before or during implementation.
Requirements
No tools or scripts required; instructions and reference documents only. The skill is not user-invocable and model invocation is disabled.

Threat Modeling (STRIDE)

Workflow

  1. Scope — Identify the system boundary, assets (PII, credentials, payments), and availability requirements (SLO/SLA).
  2. Data Flow Diagram — Map actors, entry points, data stores, and external dependencies. Mark trust boundaries (public internet → edge → internal → database → third-party).
  3. STRIDE per element — For each element in the diagram, walk through all six STRIDE categories (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) and record threats.
  4. Risk score — Rate each threat by Impact (Low/Med/High) and Likelihood (Low/Med/High). Prioritize High-impact + Med/High-likelihood items first.
  5. Mitigate — Convert each prioritized threat into engineering tasks, verification tasks (tests, alerts), and operational controls (runbooks, access reviews).
  6. Tickets and tests — Create backlog items for mitigations and add abuse-case tests for critical flows. Add PR checklist items for ongoing verification.

Example: Threat Register Row

ElementSTRIDEThreatImpactLikelihoodMitigationOwnerStatus
API GatewaySpoofingStolen JWT reuse after session revocationHighMedShort-lived tokens (15 min TTL), refresh rotation, revocation list check on each requestSecurityOpen

This single row drives three artifacts: an engineering ticket (implement revocation-list middleware), a test (verify revoked token returns 401 within TTL window), and a PR checklist item (authz checks for new endpoints).

Validation Checkpoint

Before finalizing, verify completeness:

  • Every element in the data flow diagram has at least one STRIDE entry
  • All High-impact threats have an assigned owner and mitigation
  • Each mitigation maps to a backlog ticket or test case
  • Threat model doc includes assumptions and scope boundaries
  • PR checklist updated with new security requirements

Outputs (Definition of Done)

Produce a data flow diagram, a threat register, and a mitigation plan that becomes tickets and tests.

Load Next (References)

  • references/stride-workshop.md — step-by-step workshop agenda + DFD guidance
  • references/common-threats-and-mitigations.md — threat catalog with mitigations
  • references/templates.md — copy/paste templates for docs and tickets

Source and attribution

Source:bobmatnyc/claude-mpm-skillsinuniversal/security/threat-modelingat commit718070a

License: MIT

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

Report or request removal