aio-threat-models

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:

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                      # List all 27 frameworks by volume
$TM/list-models.sh --volume 2           # Filter by volume (1-7)
$TM/list-models.sh --search "mitre"     # Search by keyword
$TM/list-models.sh --count              # Quick count per volume

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

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

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

1. STRIDE — default software-centric starting point
2. LINDDUN — privacy-native parallel to STRIDE (mandatory for PII systems)
3. Shostack 4-Questions — methodology-agnostic scaffold wrapping everything
4. DFD + Trust Boundaries — system representation for STRIDE/LINDDUN/PASTA
5. Attack Trees — quantitative analysis of high-value attack scenarios
6. MITRE ATT&CK — de-facto standard TTP catalog
7. PASTA — risk-centric methodology for regulated industries
8. MITRE ATLAS — ML-system TTP catalog
9. OWASP Top 10 for LLM — curated LLM threat checklist
10. 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 Manifesto: https://www.threatmodelingmanifesto.org/
• Adam Shostack's site: https://shostack.org/resources/threat-modeling
• OWASP Threat Modeling: https://owasp.org/www-community/Threat_Modeling
• CMU SEI Threat Modeling: https://www.sei.cmu.edu/blog/threat-modeling-12-available-methods/
• LINDDUN: https://linddun.org/
• MITRE ATT&CK: https://attack.mitre.org/
• MITRE ATLAS: https://atlas.mitre.org/
• NIST AI Resource Center: https://airc.nist.gov/

"Threat modeling is a journey of understanding — not a snapshot." — Threat Modeling Manifesto (2020)