| name | aio-threat-models |
| description | Threat modeling framework advisor — selects the right framework(s) for the system (security, privacy, AI/ML, cloud, K8s), walks through application, and composes findings across frameworks. Use proactively when reviewing architecture for risk, conducting a security architecture review, assessing a system's attack surface, enumerating threats, analyzing security posture, modeling vulnerabilities, or performing a structured risk assessment.
|
| when_to_use | threat model, security risk analysis, privacy risk, attack surface, secure architecture review, STRIDE, LINDDUN, PASTA, MITRE ATT&CK, ATLAS, Attack Tree, Kill Chain, DPIA, OWASP LLM Top 10, NIST AI RMF, adversarial ML, cloud threat modeling, Kubernetes threat, threat model as code, DFD, trust boundary |
| argument-hint | System, scope, or architecture to model |
| effort | high |
Threat Modeling Framework Advisor
"Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics."
— Threat Modeling Manifesto (2020)
Workflow: How to Use This Skill
When this skill is triggered, follow these five steps. Do NOT just dump framework descriptions — actively guide the user through their specific threat modeling task.
Step 1: ASK — Understand the System
Before selecting frameworks, gather essential context (if not already clear):
- What system is being threat modeled? (new design, existing system, specific feature)
- Is it primarily a security, privacy, or both concern?
- What domain? (web app, mobile, cloud-native, microservices, AI/ML, IoT, cyber-physical)
- Who processes the output? (developers, SOC, compliance, regulators, executives)
- What lifecycle phase? (requirements, design, implementation, operations, incident review)
- Regulatory context? (GDPR, HIPAA, PCI DSS, EU AI Act, SOC 2, etc.)
- Team expertise level? (beginners, security-experienced, dedicated security team)
If the user's message already contains enough context, proceed directly to Step 2.
Step 2: SEARCH — Find Relevant Frameworks
First, run semantic search with the user's problem as the query to find the most relevant frameworks. Then cross-reference with the routing table below.
TM="${CLAUDE_PLUGIN_ROOT}/skills/aio-threat-models/scripts"
npx tsx "$TM/search-models.ts" "<user's threat modeling problem>" --top 5 --json
Read the full markdown file for each top result before proceeding. Use the routing table as a secondary guide:
| Context | Start With |
|---|
| Starting fresh, new web/app system | Shostack 4Q + STRIDE + DFD |
| Privacy-sensitive system (PII/PHI) | LINDDUN (parallel to STRIDE) + DPIA |
| Regulated finance/healthcare | PASTA + STRIDE + DPIA (if PII) |
| Enterprise DevSecOps at scale | VAST (or IriusRisk) + Continuous TM |
| Organizational risk assessment | OCTAVE Allegro |
| High-value attack scenario | Attack Trees |
| Creative threat discovery, diverse team | Security Cards + PnG (consider hTMM) |
| Requirements-phase threat modeling | hTMM (Cards + PnG + SQUARE) |
| ML/AI system | OWASP LLM Top 10 + MITRE ATLAS + NIST AI RMF + NIST AI 100-2 |
| Cloud-native / K8s | Shared Responsibility + CNCF 4-layer + K8s Threat Matrix |
| CTI / incident analysis | Diamond Model + Kill Chain / UKC + MITRE ATT&CK |
| Agile sprint integration | Threat Model as Code (pytm / Threagile) + Continuous TM |
| Access control system | Trike (requirements matrix) |
| Scoring identified threats | CVSS or bug bars (DO NOT use DREAD — deprecated) |
| AI-phase adversarial ML rigor | NIST AI 100-2 taxonomy |
State which frameworks you selected and why they fit this situation.
Step 3: APPLY — Walk Through Each Framework
For each selected framework, apply it directly to the user's situation:
- Name the framework and its core concept (one sentence)
- State its origin and primary use case
- Show what it reveals about the user's specific problem
- Identify the concrete threats, properties, or steps relevant
Step 4: COMPOSE — Cross-Framework Synthesis
Real-world threat modeling rarely uses one framework in isolation. Compose:
- Outer loop: Shostack 4Q (what are we working on / what can go wrong / what to do / did we do a good job)
- System representation: DFD with trust boundaries
- Threat enumeration: STRIDE (security) + LINDDUN (privacy, if applicable)
- Creative brainstorm: Security Cards or PnG (for blind spots)
- Attack depth: Attack Trees for high-value scenarios
- Knowledge bases: MITRE ATT&CK / ATLAS / CAPEC for known TTPs
- Risk scoring: CVSS for vulnerabilities, PASTA risk analysis for threats
- Compliance mapping: DPIA for GDPR; AI RMF Playbook for AI governance
State the composition you recommend and how the frameworks interact.
Step 5: CHALLENGE — Stress-Test the Approach
Pick one dimension and challenge honestly:
- Coverage: What threats does this composition likely miss? (Privacy? Insider threats? Novel ML attacks?)
- Effort vs value: Is the proposed depth justified? Could a lighter approach suffice?
- Empirical limits: Remember Scandariato 2015 — STRIDE misses threats systematically. Consider pairing with creative methods.
- Tool reality: Does the team have skills/tools for this? Or will it degrade to "admiration for the problem" (Manifesto anti-pattern)?
State final confidence level and any caveats.
Scripts
Before calling any script, resolve the scripts directory:
TM="${CLAUDE_PLUGIN_ROOT}/skills/aio-threat-models/scripts"
List all frameworks
$TM/list-models.sh
$TM/list-models.sh --volume 2
$TM/list-models.sh --search "mitre"
$TM/list-models.sh --count
Semantic Search
Find relevant frameworks by meaning, not just keywords. Uses pre-computed embeddings (snowflake-arctic-embed-xs, 384-dim, runs locally).
npx tsx "$TM/search-models.ts" "how to model privacy threats in an ML system"
npx tsx "$TM/search-models.ts" "framework for kubernetes security review" --top 3
npx tsx "$TM/search-models.ts" "enterprise threat modeling at scale" --json
Options:
--top N — Number of results (default: 5)--json — Output as JSON
Always run semantic search first before selecting frameworks. The search uses embeddings to find the most relevant frameworks for the user's specific problem — more reliable than guessing from memory.
Rebuild embeddings (after adding or editing content)
npx tsx "$TM/build-embeddings.ts"
Framework Catalog
7 Volumes, 27 frameworks total. Each framework has its own markdown file with: core concept, origin, structure, when-to-use, strengths, limitations, relation to other frameworks, and primary-source references.
Volume 1: Foundations
Methodology-agnostic scaffolds and common artifacts
Volume 2: Core Frameworks
The six most widely-deployed threat modeling frameworks
| Framework | Core Idea | Best For |
|---|
| STRIDE | 6 threat categories for software-centric TM | Default web/app starting point |
| DREAD | Risk scoring (deprecated) | Historical reference; don't use |
| PASTA | 7-stage risk-centric methodology | Regulated industries |
| OCTAVE Allegro | Asset-centric organizational risk | SMB / periodic audit |
| Trike | Requirements-based actor-asset-action matrix | Formal access control |
| VAST | Enterprise DevSecOps (dual-track) | Large organizations |
Volume 3: Attacker-centric
Frameworks grounded in adversary modeling
Volume 4: Attack Patterns
Knowledge bases of real-world adversary behaviors
Volume 5: Privacy
Privacy-specific frameworks and regulatory counterparts
| Framework | Core Idea |
|---|
| LINDDUN | 7 privacy threat categories + GO (card) + MAESTRO |
| GDPR DPIA | Article 35 Data Protection Impact Assessment structure |
Volume 6: AI/ML Threat Modeling
Frameworks for LLM, ML, and AI systems
Volume 7: Cloud & DevSecOps
Cloud-native, microservices, and continuous threat modeling
Quick Reference — Framework Selection Matrix
By Orientation
- Software-centric: STRIDE, LINDDUN
- Asset-centric: OCTAVE Allegro
- Attacker-centric: Attack Trees, PnG, Security Cards, Kill Chain, UKC, ATT&CK
- Risk-centric: PASTA, Trike
- Hybrid: hTMM, VAST (dual-track)
- Analyst-centric: Diamond Model
By Lifecycle Phase
- Requirements: hTMM, PnG, Misuse Cases
- Design / Architecture: STRIDE, LINDDUN, Attack Trees, PASTA
- Implementation: Threat Model as Code (pytm, Threagile)
- Operations / SOC: MITRE ATT&CK, Kill Chain, UKC, Diamond Model
- Incident Analysis: Diamond Model, ATT&CK, CAPEC
By Scope
- Security only: STRIDE, PASTA, Attack Trees, Kill Chain
- Privacy only: LINDDUN, DPIA
- Security + Privacy: STRIDE + LINDDUN in parallel (best practice)
- AI/ML: OWASP LLM Top 10 + ATLAS + NIST AI RMF + NIST AI 100-2
- Cloud: Shared Responsibility + CSA + cloud-provider-specific
- Organizational: OCTAVE Allegro
Top 10 Most-Used Frameworks
- STRIDE — default software-centric starting point
- LINDDUN — privacy-native parallel to STRIDE (mandatory for PII systems)
- Shostack 4-Questions — methodology-agnostic scaffold wrapping everything
- DFD + Trust Boundaries — system representation for STRIDE/LINDDUN/PASTA
- Attack Trees — quantitative analysis of high-value attack scenarios
- MITRE ATT&CK — de-facto standard TTP catalog
- PASTA — risk-centric methodology for regulated industries
- MITRE ATLAS — ML-system TTP catalog
- OWASP Top 10 for LLM — curated LLM threat checklist
- Continuous Threat Modeling — modern DevSecOps practice
Empirical Reminders
From the literature (Scandariato 2015, Tuma 2018, Xiong 2019):
- STRIDE has a high false-negative rate — practitioners miss threats systematically. Pair with Security Cards or PnG for creative breadth.
- No framework optimizes all properties (SEI 2018). Composition > choosing one.
- No Definition of Done exists in threat analysis (Tuma 2018). Completeness cannot be objectively measured.
- Most validation is by illustration, not controlled empirical evaluation.
- Manual analysis dominates — automation nascent but improving.
Anti-Patterns to Avoid
From Threat Modeling Manifesto (2020):
- Hero Threat Modeler — one expert bottlenecks everything
- Admiration for the Problem — endless analysis without action
- Tendency to Overfocus — over-analyzing one area, ignoring others
- Perfect Representation — weeks perfecting a DFD that's outdated by next sprint
Plus community-derived:
- Using DREAD — subjective, deprecated; use CVSS or bug bars
- STRIDE-only for PII systems — misses 5 privacy threat categories; always pair with LINDDUN
- One-time threat modeling — Manifesto value: "Continuous refinement over single delivery"
- Automation theater — generating reports no one reads
Sources & Further Reading
Canonical Books
- Shostack, A. (2014). Threat Modeling: Designing for Security. Wiley.
- UcedaVélez, T., Morana, M.M. (2015). Risk Centric Threat Modeling. Wiley.
- Tarandach, I., Coles, M. (2020). Threat Modeling: A Practical Guide for Development Teams. O'Reilly.
- Swiderski, F., Snyder, W. (2004). Threat Modeling. Microsoft Press.
Systematic Literature Reviews
- Scandariato, R., Wuyts, K., Joosen, W. (2015). "A descriptive study of Microsoft's threat modeling technique". Requirements Engineering 20:163–180.
- Tuma, K., Calikli, G., Scandariato, R. (2018). "Threat analysis of software systems: A systematic literature review". Journal of Systems and Software 144:275–294.
- Xiong, W., Lagerström, R. (2019). "Threat modeling — A systematic literature review". Computers & Security 84:53–69.
Online Resources
"Threat modeling is a journey of understanding — not a snapshot."
— Threat Modeling Manifesto (2020)
