sota-threat-modelinglisted

State-of-the-art threat modeling for both designing new systems and auditing existing ones. Use when designing a feature, service, integration, or architecture that touches untrusted input, new trust boundaries, sensitive data, or third-party dependencies (BUILD mode), and when reviewing, auditing, or pen-test-scoping an existing codebase to reconstruct its implicit threat model and find gaps (AUDIT mode). Not for code-level vulnerability review — use sota-code-security. Trigger keywords: threat model, STRIDE, LINDDUN, PASTA, attack tree, kill chain, data flow diagram, DFD, trust boundary, attack surface, abuse case, security design review, security architecture review, risk rating, DREAD, CVSS, security requirements, secure design, security audit, gap analysis, prompt injection, excessive agency, threat catalog, mitigations, residual risk.
martinholovsky/SOTA-skills · ★ 8 · AI & Automation · score 75

Install: claude install-skill martinholovsky/SOTA-skills

# SOTA Threat Modeling ## Purpose Threat modeling answers Shostack's four questions with engineering rigor: 1. **What are we working on?** (decompose: DFD, trust boundaries, assets, actors) 2. **What can go wrong?** (enumerate: STRIDE/LINDDUN per element, catalogs, attack trees) 3. **What are we going to do about it?** (treat: mitigate/accept/transfer/avoid, map to requirements and tests) 4. **Did we do a good job?** (verify: abuse-case tests, residual risk review, re-model triggers) This skill operationalizes those questions in two modes. Never produce a threat model that is only prose — every threat must land as a tracked requirement, a test, or an explicitly accepted risk with an owner. ## BUILD Mode — Threat-Model-While-Designing Run this workflow whenever designing anything that crosses a trust boundary. Scale effort to risk: a 15-minute "four questions" pass for a small feature; a full STRIDE-per-interaction model for a new service or auth flow. ### Workflow 1. **Scope the delta.** Model what is new or changed, not the whole system. List new entry points, new data classes, new dependencies, new actors. 2. **Draw the DFD as text/mermaid** (see `rules/02`). Mark trust boundaries explicitly. If you cannot draw a boundary, you do not understand the design yet — stop and ask. 3. **Pick the methodology** (see `rules/01`): STRIDE-per-interaction by default; add LINDDUN if personal data flows; attack trees for a single high-value asset; four-questions-only