Threat model

Skill byerlikaya/claude-starter-kit/claude-starter/skills/threat-model

Enterprise engineering workflow for Claude Code — not just prompts. AI agents that plan, build, audit, and ship with security gates, privacy checks, and approval-controlled commits. Safely adopt it into new or existing repositories.

Install

npx -y skills add byerlikaya/claude-starter-kit --skill threat-model

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Scope a security audit BEFORE scanning, to cut false positives: map assets, entry points, trust boundaries and 5-8 domain-specific attack classes into a parseable THREAT_MODEL.md. A threat survives a patch; a vulnerability is only evidence for one. Feeds security-scan. Trigger phrases: "threat model", "attack surface", "scope the audit", "trust boundary"

SKILL.md

3.3 KB, as published. Nobody here has run it

Threat Model

Scope first, scan second. A security scan with no map produces noise; a threat model tells the scanner (and security-scan) where to look and what matters — the single biggest lever on false positives.

The one idea to keep — the litmus test: if patching one line of code makes an entry disappear, it was a vulnerability, not a threat. Threats survive patching (they name what an attacker wants and the surface they arrive through); a vulnerability is only evidence that raises a threat's likelihood.

Kit adaptation (local, .claude/): security-expert-csk runs this to scope before security-scan. Output docs/THREAT_MODEL.md is internal (§4.3). Stack-agnostic. §4 Prohibitions apply.

When

Before a first security-scan of a system, or when scan output is noisy / unscoped.
After a significant new surface — a new API, a new integration, a new trust boundary.

Two modes

interview — the owner is available: ask the four questions below, one at a time.
bootstrap — no owner: derive the model from code + past advisories, then flag what only the owner can confirm.

Method — the four questions (Shostack), one at a time

Never dump a questionnaire; ask, capture into the schema, move on. Mirror the user's language.

What are we building? system context, assets worth protecting, entry points and trust boundaries.
What can go wrong? open-ended first; then, per entry point, fall back to STRIDE; derive 5-8 domain-specific attack classes at the right granularity — "IDOR on dataset rows", "integer overflow on length fields" — not "web vulnerabilities".
What are we doing about it? impact · residual likelihood · status · controls per threat; "accept the risk, with a written reason" (risk_accepted) is a valid answer.
Did we do a good job? read the ranked table back; coverage-check that every entry point appears.

Tag every fact [Code-verified] or [Owner-states]; each owner claim that moves a score becomes an open question with a "Verify by:" note.

Output

Write docs/THREAT_MODEL.md to the parseable contract in references/schema.md (fixed sections; a threats table with enumerated columns; residual-likelihood scoring; class-level mitigations). The interview flow, the STRIDE table, and the bootstrap steps live in references/interview.md.

Principles

Evidence raises likelihood; it is not the threat. Score the residual likelihood after current controls; a stated-but-unverified control does not lower it — it becomes an open question.
Prefer a control that survives the next bug over a patch for the last one (class-level mitigations).
Feeds forward: security-scan reads THREAT_MODEL.md to scope its fronts and bias severity.

DoD

docs/THREAT_MODEL.md exists; every entry point covered; each threat scored; provenance tagged; scope handed to security-scan.