threat-model

Name: threat-model
Author: anthropics

6.7kstars543forks

How to install threat-model?

anthropics/defending-code-reference-harness/threat-model

$npx -y skills add anthropics/defending-code-reference-harness --skill threat-model

Installs into the current project.

Summary

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, pente

Files · 1

View on GitHub

SKILL.md

1	# threat-model
2
3	A threat model answers **"what could go wrong with this system, who would do
4	it, and what should we do about it?"** independently of whether any specific
5	bug has been found yet. It is the map; vulnerability discovery is the metal
6	detector. A good threat model tells the pipeline where to look and tells triage
7	which findings matter.
8
9	Litmus test: If patching one line of code makes an entry disappear, it was
10	a vulnerability, not a threat. A threat ("attacker achieves RCE via untrusted
11	media parsing") still stands after every known bug is fixed; a vulnerability
12	("`dr_wav.h:412` doesn't bounds-check `chunk_size`") does not. This skill
13	produces threats. Vulnerabilities appear only as evidence that raises a
14	threat's likelihood score.
15
16	Invocation: `/threat-model [bootstrap-then-interview\|bootstrap\|interview] <target-dir> [flags]`
17
18	---
19
20	## Step 0 — Safety preamble (always runs first)
21
22	This skill performs static analysis only. It reads source, git history,
23	and any vulnerability reports the user supplies, and writes a single output
24	file (`<target-dir>/THREAT_MODEL.md`). It does not build, execute, fuzz, or
25	modify the target, and does not make network requests against the target's
26	infrastructure.
27
28	Before proceeding, confirm and state in your first response:
29
30	1. The target directory exists and is a local checkout you can read.
31	2. You will not execute any code from the target directory.
32	3. If `--vulns` points at a URL or you are asked to "fetch CVEs", you will
33	query only public advisory databases (NVD, GitHub Security Advisories, the
34	project's own issue tracker) and never the target's live deployment.
35
36	If the user asks you to validate a threat by running an exploit, decline and
37	point them at the `vuln-pipeline` (README Step 2) instead.
38
39	---
40
41	## Step 1 — Route to a mode
42
43	Parse `$ARGUMENTS`:
44
45	\| First token \| Route to \|
46	\|---\|---\|
47	\| `interview` \| Read `interview.md` in this directory and follow it. \|
48	\| `bootstrap` \| Read `bootstrap.md` in this directory and follow it. \|
49	\| `bootstrap-then-interview` \| Bootstrap first, then interview seeded from the draft. See below. \|
50	\| 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`. \|
51
52	All modes write the same artifact (`THREAT_MODEL.md`, schema in `schema.md`)
53	so downstream consumers (pipeline `recon`/`judge`, verifier agents) do not need
54	to know which mode produced it.
55
56	\| \| `interview` \| `bootstrap` \|
57	\|---\|---\|---\|
58	\| Needs \| An application owner present in the session \| A local checkout; optionally past vulns \|
59	\| 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 \|
60	\| 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 \|
61	\| Provenance tag \| `interview` \| `bootstrap` \|
62
63	Context durability. Interview mode is multi-turn; tool results from early
64	reads may be evicted before you need them. To stay resilient:
65
66	- Do not read `interview.md` or `bootstrap.md` in full up front. Read the
67	mode file (or the relevant section of it) at the point you need it, one
68	question or stage at a time.
69	- If a re-read via the Read tool is refused as "file unchanged", the prior
70	result was evicted; reload with `cat <path>` via Bash instead.
71
72	Interview backbone (so you can proceed even if `interview.md` is
73	unavailable mid-session):
74
75	\| Q \| Question \| Fills schema sections \|
76	\|---\|---\|---\|
77	\| Q1 \| What are we working on? \| section 1 context, s

People who liked this also viewed

6 picks

Type

threat-model

6.7kstars543forks

View on GitHub

How to install threat-model?

anthropics/defending-code-reference-harness/threat-model

$npx -y skills add anthropics/defending-code-reference-harness --skill threat-model

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# threat-model
2
3	A threat model answers **"what could go wrong with this system, who would do
4	it, and what should we do about it?"** independently of whether any specific
5	bug has been found yet. It is the map; vulnerability discovery is the metal
6	detector. A good threat model tells the pipeline where to look and tells triage
7	which findings matter.
8
9	Litmus test: If patching one line of code makes an entry disappear, it was
10	a vulnerability, not a threat. A threat ("attacker achieves RCE via untrusted
11	media parsing") still stands after every known bug is fixed; a vulnerability
12	("`dr_wav.h:412` doesn't bounds-check `chunk_size`") does not. This skill
13	produces threats. Vulnerabilities appear only as evidence that raises a
14	threat's likelihood score.
15
16	Invocation: `/threat-model [bootstrap-then-interview\|bootstrap\|interview] <target-dir> [flags]`
17
18	---
19
20	## Step 0 — Safety preamble (always runs first)
21
22	This skill performs static analysis only. It reads source, git history,
23	and any vulnerability reports the user supplies, and writes a single output
24	file (`<target-dir>/THREAT_MODEL.md`). It does not build, execute, fuzz, or
25	modify the target, and does not make network requests against the target's
26	infrastructure.
27
28	Before proceeding, confirm and state in your first response:
29
30	1. The target directory exists and is a local checkout you can read.
31	2. You will not execute any code from the target directory.
32	3. If `--vulns` points at a URL or you are asked to "fetch CVEs", you will
33	query only public advisory databases (NVD, GitHub Security Advisories, the
34	project's own issue tracker) and never the target's live deployment.
35
36	If the user asks you to validate a threat by running an exploit, decline and
37	point them at the `vuln-pipeline` (README Step 2) instead.
38
39	---
40
41	## Step 1 — Route to a mode
42
43	Parse `$ARGUMENTS`:
44
45	\| First token \| Route to \|
46	\|---\|---\|
47	\| `interview` \| Read `interview.md` in this directory and follow it. \|
48	\| `bootstrap` \| Read `bootstrap.md` in this directory and follow it. \|
49	\| `bootstrap-then-interview` \| Bootstrap first, then interview seeded from the draft. See below. \|
50	\| 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`. \|
51
52	All modes write the same artifact (`THREAT_MODEL.md`, schema in `schema.md`)
53	so downstream consumers (pipeline `recon`/`judge`, verifier agents) do not need
54	to know which mode produced it.
55
56	\| \| `interview` \| `bootstrap` \|
57	\|---\|---\|---\|
58	\| Needs \| An application owner present in the session \| A local checkout; optionally past vulns \|
59	\| 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 \|
60	\| 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 \|
61	\| Provenance tag \| `interview` \| `bootstrap` \|
62
63	Context durability. Interview mode is multi-turn; tool results from early
64	reads may be evicted before you need them. To stay resilient:
65
66	- Do not read `interview.md` or `bootstrap.md` in full up front. Read the
67	mode file (or the relevant section of it) at the point you need it, one
68	question or stage at a time.
69	- If a re-read via the Read tool is refused as "file unchanged", the prior
70	result was evicted; reload with `cat <path>` via Bash instead.
71
72	Interview backbone (so you can proceed even if `interview.md` is
73	unavailable mid-session):
74
75	\| Q \| Question \| Fills schema sections \|
76	\|---\|---\|---\|
77	\| Q1 \| What are we working on? \| section 1 context, s

People who liked this also viewed

6 picks

Type