# Threat Model

Build a threat model for a target codebase.

- Repository: https://github.com/anthropics/defending-code-reference-harness (7690 stars)
- Category: Security
- License: see repository
- Last updated: 2026-08-06
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add anthropics/defending-code-reference-harness --skill threat-model -g -a claude-code -y`
Codex: `npx skills add anthropics/defending-code-reference-harness --skill threat-model -g -a codex -y`
Cursor: `npx skills add anthropics/defending-code-reference-harness --skill threat-model -g -a cursor -y`
Gemini CLI: `npx skills add anthropics/defending-code-reference-harness --skill threat-model -g -a gemini-cli -y`

## Description

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".

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

1. The target directory exists and is a local checkout you can read.
2. You will not execute any code from the target directory.
3. If `--vulns` points 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`:

The rest: https://github.com/anthropics/defending-code-reference-harness/blob/HEAD/.claude/skills/threat-model/SKILL.md