
threat-model
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 THREATMODEL.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".
- Installs
- 1.2K
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/anthropics/defending-code-reference-harness --skill threat-model- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads threat-model automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
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:
| First token | Route to |
|---|---|
interview | Read interview.md in this directory and follow it. |
bootstrap | Read bootstrap.md in this directory and follow it. |
bootstrap-then-interview | Bootstrap first, then interview seeded from the draft. See below. |
| anything else, or empty | Ask the user: "Is someone who owns or built this system available to answer questions in this session?" Yes and the codebase is checked out → recommend bootstrap-then-interview. Yes but no codebase → interview.md. No → bootstrap.md. |
All modes write the same artifact (THREAT_MODEL.md, schema in schema.md)
so downstream consumers (pipeline recon/judge, verifier agents) do not need
to know which mode produced it.
interview | bootstrap | |
|---|---|---|
| Needs | An application owner present in the session | A local checkout; optionally past vulns |
| Method | Four-question framework: conversational walk through what are we working on → what can go wrong → what are we going to do about it → did we do a good job | Five stages: parallel research swarm → synthesize sections 1-3 + vuln table → generalize vulns into threat classes → STRIDE gap-fill → emit |
| Best for | New systems, design reviews, systems where the risk lives in business logic the code doesn't show | Inherited systems, third-party code, OSS dependencies, anything with a CVE history |
| Provenance tag | interview | bootstrap |
Context durability. Interview mode is multi-turn; tool results from early reads may be evicted before you need them. To stay resilient:
- Do not read
interview.mdorbootstrap.mdin full up front. Read the mode file (or the relevant section of it) at the point you need it, one question or stage at a time. - If a re-read via the Read tool is refused as "file unchanged", the prior
result was evicted; reload with
cat <path>via Bash instead.
Interview backbone (so you can proceed even if interview.md is
unavailable mid-session):
| Q | Question | Fills schema sections |
|---|---|---|
| Q1 | What are we working on? | section 1 context, section 2 assets, section 3 entry points |
| Q2 | What can go wrong? | section 4 threat rows (id, threat, actor, surface, asset) |
| Q3 | What are we going to do about it? | section 4 impact/likelihood/status/controls; section 5 deprioritized; section 8 recommended mitigations |
| Q4 | Did we do a good job? | validate ranking, coverage check, section 6 open questions |
bootstrap-then-interview mode
When the owner is available and the codebase is checked out, this is the recommended path: the owner's time goes to refining a code-grounded draft instead of describing the system from scratch.
- Tell the owner: "I'll read the code first and come back with a draft
(about 5-10 min), then we'll walk it together. Want that, or would you
rather start cold?" Only proceed if they opt in; otherwise fall back to
interview.md. - Read
bootstrap.mdand follow it end-to-end. Write<target-dir>/THREAT_MODEL.md. - Immediately continue into interview mode: read
interview.mdand follow it with--seed <target-dir>/THREAT_MODEL.mdin effect. The section 6 open questions from bootstrap become your Q1-Q4 prompts; the owner confirms, corrects, and adds rather than starting from nothing. - Overwrite
<target-dir>/THREAT_MODEL.mdwith the refined model. Set provenancemode: bootstrap-then-interview.
The same flow is available manually: run bootstrap first, then
interview --seed <THREAT_MODEL.md> in a later session.
Step 2 — Shared output contract
All modes MUST emit <target-dir>/THREAT_MODEL.md conforming to schema.md
in this directory. Read schema.md immediately before you write the file,
not at routing time; in interview mode the gap between routing and emit can be
many turns, and an early read will be evicted before it's used.
After writing the file, print to the user:
- The path to
THREAT_MODEL.md. - The top 5 threats by likelihood × impact (id, one-line description, L×I).
- For
bootstrap: any open questions the code could not answer (these seed a laterinterviewpass). - For
interview: any owner statements that could not be verified in code (these seed follow-up code review).
References
- docs/security.md and docs/prompting.md for the engagement-context and authorization framing this skill inherits.
FAQ
What does the threat-model skill do?
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 THREATMODEL.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".
How do I install threat-model?
Run npx skills add https://github.com/anthropics/defending-code-reference-harness --skill threat-model in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/threat-model/ (personal) or .claude/skills/threat-model/ (project).
Which AI agents can use threat-model?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is threat-model safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains threat-model?
It is published by anthropics in anthropics/defending-code-reference-harness. It has 1,241 recorded installs.
More from anthropics/defending-code-reference-harness
vuln-scan
anthropics/defending-code-reference-harness
Static source-code vulnerability scan. Reads a target directory (and THREATMODEL.md if present), spawns parallel review subagents per focus area, and writes VULN-FINDINGS.json + .md for /triage to consume. Read-only — no building, running, or network. For execution-verified crashes, use vuln-pipeline instead. Use when asked to "scan for vulns", "review this code for security issues", "find bugs in ", or as the step between /threat-model and /triage.
triage
anthropics/defending-code-reference-harness
Triage a batch of raw security findings. Verify each is real, collapse duplicates, re-rank by derived exploitability, and tag with an owner. Takes a directory or file of scanner output and writes TRIAGE.json + TRIAGE.md sorted by what actually needs engineering attention. Use when asked to "triage findings", "validate scanner output", "prioritize vulns", or "review the backlog". Runs interactively by default; pass --auto to skip the interview.
patch
anthropics/defending-code-reference-harness
Generate candidate fixes for verified security findings. Consumes TRIAGE.json (preferred), VULN-FINDINGS.json, INCIDENTS.json, or a vuln-pipeline results directory. Pipeline input is delegated to the execution-verified vuln-pipeline patch ladder; static-analysis input gets a per-finding patch subagent + independent reviewer and is written as inert diffs for human review. Writes PATCHES/bugNN/{patch.diff,patchresult.json}, PATCHES.md, and PATCHES.json. Use when asked to "fix the findings", "patch these vulns", "generate fixes", or "close the loop on triage".
customize
anthropics/defending-code-reference-harness
Adapt this C/C++ ASAN vulnerability pipeline to a different vulnerability class, target shape, language, or detection mechanism. Use when the user wants to port, migrate, retarget, customize, or fork the pipeline for something other than C/C++ memory-safety bugs — web apps, smart contracts, deserialization, ML systems, or any other domain.
quickstart
anthropics/defending-code-reference-harness
The front door for this repo. With no argument: a 30-second intro, then an offer to walk you through your first run on the canary target. With a question: answers it from this repo's own docs and source, cites where it looked, and hands you the next command. Use for "how do I…", "why does…", "where is…", "can this…", or just "/quickstart" to get oriented.
verify
anthropics/defending-code-reference-harness
Verify harness changes end-to-end without docker — drive the real pinned CLI against a header-capturing stub server with the exact env resolveauthenv() produces.
Popular security skills
azure-compliance
microsoft/azure-skills
Run Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: compliance scan, security audit, BEFORE running azqr (compliance cli tool), Azure best practices, Key Vault expiration check, expired certificates, expiring secrets, orphaned resources, compliance assessment.
minimal-run-and-audit
lllllllama/rigorpilot-skills
Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized reprooutputs/ files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.
seo-audit
coreyhaines31/marketingskills
When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," "indexing issues," "stuck on page 2," "striking distance keywords," "title tag rewrite," "low CTR," "local SEO," "Google Business Profile," or "map pack." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema. For AI search optimization, see ai-seo.
firebase-security-rules-auditor
firebase/agent-skills
Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.
audit
pbakaus/impeccable
Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.
competitors
coreyhaines31/marketingskills
When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'competitor teardown,' 'audit our competitor pages,' 'are our comparison pages out of date,' or 'competitive asset audit.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For auditing existing claims (not researching competitors from scratch, which is competitor-profiling; not technical SEO on these pages, which is seo-audit), use the asset audit here. For internal battle cards and sales-specific competitor docs, see sales-enablement.