Threat Model
Build a threat model for a target codebase.
Install
npx skills add anthropics/defending-code-reference-harness --skill threat-model -g -a claude-code -y- Repository
- anthropics/defending-code-reference-harness7.7k
- Category
- Security
- Updated
- 3mo ago
- License
- See repository
- Context cost
- Mediumabout 1,590 tokens
- Runs scripts
- No, instructions only
What it does
Build a threat model for a target codebase. Three modes: "interview" walks an application owner through the four-question framework and produces a threat model from their answers; "bootstrap" derives a threat model from the code plus past vulnerabilities (CVEs, git history, pentest reports) when no owner is available; "bootstrap-then-interview" chains the two when both owner and codebase are present. All write THREAT_MODEL.md in a shared schema. Use when asked to "threat model", "build a threat model", "map the attack surface", or "what should we be worried about in this codebase".
threat-model
A threat model answers "what could go wrong with this system, who would do it, and what should we do about it?" independently of whether any specific bug has been found yet. It is the map; vulnerability discovery is the metal detector. A good threat model tells the pipeline where to look and tells triage which findings matter.
Litmus test: If patching one line of code makes an entry disappear, it was
a vulnerability, not a threat. A threat ("attacker achieves RCE via untrusted
media parsing") still stands after every known bug is fixed; a vulnerability
("dr_wav.h:412 doesn't bounds-check chunk_size") does not. This skill
produces threats. Vulnerabilities appear only as evidence that raises a
threat's likelihood score.
Invocation: /threat-model [bootstrap-then-interview|bootstrap|interview] <target-dir> [flags]
Step 0, Safety preamble (always runs first)
This skill performs static analysis only. It reads source, git history,
and any vulnerability reports the user supplies, and writes a single output
file (<target-dir>/THREAT_MODEL.md). It does not build, execute, fuzz, or
modify the target, and does not make network requests against the target's
infrastructure.
Before proceeding, confirm and state in your first response:
- The target directory exists and is a local checkout you can read.
- You will not execute any code from the target directory.
- If
--vulnspoints at a URL or you are asked to "fetch CVEs", you will query only public advisory databases (NVD, GitHub Security Advisories, the project's own issue tracker) and never the target's live deployment.
If the user asks you to validate a threat by running an exploit, decline and
point them at the vuln-pipeline (README Step 2) instead.
Step 1, Route to a mode
Parse $ARGUMENTS:
