home / skills / bobmatnyc / claude-mpm-skills / threat-modeling

threat-modeling skill

safe

This skill helps you model threats for software systems by producing a data flow diagram, threat register, and mitigations turned into backlog tickets.

npx playbooks add skill bobmatnyc/claude-mpm-skills --skill threat-modeling

Review the files below or copy the command above to add this skill to your agents.

Files (5)

SKILL.md

1.3 KB

---
name: threat-modeling
description: "Threat modeling workflow for software systems: scope, data flow diagrams, STRIDE analysis, risk scoring, and turning mitigations into backlog and tests"
version: 1.0.0
category: universal
author: Claude MPM Team
license: MIT
progressive_disclosure:
  entry_point:
    summary: "Run a lightweight threat modeling workshop (STRIDE) and turn risks into concrete mitigations, tests, and PR checks"
    when_to_use: "When designing new features, reviewing architecture changes, handling sensitive data, or hardening auth/payment/multi-tenant flows"
    quick_start: "1. Define scope/assets 2. Draw data flows + trust boundaries 3. STRIDE per element 4. Score + prioritize 5. Track mitigations + tests"
  token_estimate:
    entry: 150
    full: 8000
context_limit: 900
tags:
  - security
  - threat-modeling
  - stride
  - architecture
  - risk
requires_tools: []
---

# Threat Modeling (STRIDE)

## 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

Overview

This skill provides a repeatable threat-modeling workflow for software systems, producing a data flow diagram, a prioritized threat register, and a mitigation plan that converts findings into backlog tickets and testable acceptance criteria. It integrates STRIDE analysis, risk scoring, and practical templates so teams can move from analysis to work items and verification quickly.

How this skill works

You define scope and assets, create a data flow diagram (DFD) to visualize components and trust boundaries, and run STRIDE analysis across DFD elements to enumerate threats. Each threat is scored for likelihood and impact, turned into a threat register, and mapped to concrete mitigations that become tickets and tests using provided templates and guidance.

When to use it

Design phase of a new system or major feature to find design-level security gaps
Before security reviews or architecture sign-offs to provide concrete evidence and remediation plans
During threat workshops to align cross-functional teams on risks and responsibilities
When triaging security findings to decide what requires design changes versus configuration fixes
To convert security analysis into actionable backlog items and test cases for QA

Best practices

Scope narrowly for each session; model one user story or subsystem at a time for clarity
Keep DFDs simple and iterate; capture trust boundaries and data stores explicitly
Use STRIDE categories systematically across each DFD element to avoid missed threat classes
Apply consistent risk scoring criteria (impact × likelihood) and document assumptions
Convert mitigations into small, testable tickets with acceptance criteria and automated tests where possible

Example use cases

Run a pre-release workshop to produce a DFD, threat register, and a sprint of mitigation tickets
Augment a pull request by mapping code changes to threat model elements and required tests
Assess a third-party integration by modeling data flows and identifying authorization and confidentiality risks
Prioritize remediation after a security assessment by scoring threats and scheduling fixes into the backlog

FAQ

What deliverables will I get from a session?

A DFD, a threat register with STRIDE findings and risk scores, and a mitigation plan split into backlog tickets and testable acceptance criteria.

How granular should the DFD be?

Model at the subsystem or feature level for focused sessions; expand detail only when a threat requires deeper analysis.