Threat Model

threat-model

First leg of the defending-code loop (/threat-model → /vuln-scan → /triage → /patch), and an optional one — the loop can start at /vuln-scan. Running this first is what makes later steps scope to real attack surface and rank by impact on a named asset.

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 readable local checkout.
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: this skill is static analysis only. Execution-verified validation belongs in a sandboxed harness (see ../vuln-scan/HARNESS.md) or the user's own sandbox.

Step 1 — Route to a mode

Parse $ARGUMENTS:

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.

Context durability. Interview mode is multi-turn; tool results from early reads may be evicted before they are needed. To stay resilient:

• Do not read interview.md or bootstrap.md in full up front. Read the mode file (or the relevant section of it) at the point it is needed, 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 the run can proceed even if interview.md is unavailable mid-session):

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.

1. 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.
2. Read bootstrap.md and follow it end-to-end. Write <target-dir>/THREAT_MODEL.md.
3. Immediately continue into interview mode: read interview.md and follow it with --seed <target-dir>/THREAT_MODEL.md in effect. The section 6 open questions from bootstrap become the Q1-Q4 prompts; the owner confirms, corrects, and adds rather than starting from nothing.
4. Overwrite <target-dir>/THREAT_MODEL.md with the refined model. Set provenance mode: 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 writing 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:

1. The path to THREAT_MODEL.md.

2. The top 5 threats by likelihood × impact (id, one-line description, L×I).

3. For bootstrap: any open questions the code could not answer (these seed a later interview pass).

4. For interview: any owner statements that could not be verified in code (these seed follow-up code review).

5. The next step in the loop, as a runnable line:

   Next step: > /vuln-scan <target-dir>
   

   /vuln-scan picks up THREAT_MODEL.md from <target-dir> automatically and uses its entry points, assets, and threat classes to scope the scan and calibrate severity. Full loop: /threat-model → /vuln-scan → /triage → /patch.

Authorization framing

This skill assumes authorized security work: permission to review the target exists (the operator's own code, their org's, an OSS dependency they operate, or an engagement with a defined scope). State that assumption in the first response. Static review of readable source is low-risk, but the resulting threat model can name real attack surface — treat it as any internal security artifact.

Provenance & the autonomous harness

Adapted (Apache-2.0) from the threat-model skill in anthropics/defending-code-reference-harness. The companion autonomous discovery pipeline (C/C++ + AddressSanitizer reference) lives there; see ../vuln-scan/HARNESS.md for how to run it. The repo-kind baseline table and the per-entry-point-kind STRIDE mapping in interview.md §Q2 are adapted (Apache-2.0) from visa/visa-vulnerability-agentic-harness's s2 _BASELINES / _STRIDE_BY_KIND, including its rule that a baseline class with no matching surface in the evidence is omitted silently.