Claude Skill

create-threat-model

Analyze a codebase and produce a structured threat model at .turbo/threat-model.md covering assets, trust boundaries, attack surfaces with existing mitigations, attacker stories, and calibrated severity. Use when the user asks to "create a threat model", "threat model", "threat m

LLM Mart · 0 points · 19 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download tobihagemann-turbo-claude_skills_create-threat-model-b903a85.zip · 9 KB

tobihagemann/turbo 403 31 forks MIT Updated 1d ago

Part of tobihagemann/turbo — 147 skills

Install

skills CLI npx skills add https://github.com/tobihagemann/turbo/tree/main/claude/skills/create-threat-model

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install tobihagemann-turbo@llmmart

Git git clone https://github.com/tobihagemann/turbo.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole tobihagemann/turbo collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Create Threat Model

Analyze the current codebase and produce a structured threat model at .turbo/threat-model.md.

The threat model describes the current state of the codebase: what it protects, where trust boundaries are, how it can be attacked, what defenses exist, and how severe each risk is. It is descriptive, not prescriptive. Do not include remediation recommendations.

Optional: $ARGUMENTS may specify scope (directories, modules, or focus areas). When scope is provided, limit reconnaissance and code discovery to the specified directories or modules. Still produce all four sections, but title the overview to reflect the narrowed scope and note what is excluded.

Step 1: Reconnaissance

Build a mental model of the system before analyzing threats.

Read the project README, CLAUDE.md, and any architecture or security documentation.
Examine top-level directory structure, build files, and dependency manifests to identify modules, languages, frameworks, and deployment model.
Classify the application type: library, CLI tool, web service, desktop app, mobile app, or hybrid. This determines which threat categories and trust boundary patterns apply.
Identify security-critical dependencies (crypto libraries, auth providers, network stacks, native/FFI libraries). Note what this codebase delegates versus what it owns.
Read any existing security documentation: SECURITY.md, audit reports, threat models, or changelog entries mentioning CVEs.

Step 2: Security-Relevant Code Discovery

Search the codebase for code that handles security-sensitive operations. Do not read every file. Use targeted searches.

Categories to search for:

Authentication and authorization (login, OAuth, tokens, sessions, RBAC, API keys)
Cryptographic operations (encryption, signing, hashing, key generation, key derivation)
Secret and credential storage (keychains, vaults, env vars, config files with secrets)
Network communication (HTTP clients, TLS configuration, certificate handling, WebSocket, gRPC)
Untrusted input processing (file parsing, deserialization, XML/JSON/YAML from external sources)
IPC and process boundaries (sockets, pipes, CLI subprocesses, shared memory)
Plugin and extension loading (dynamic imports, ServiceLoader, plugin directories)
Update and distribution mechanisms (auto-update, download verification, signature checking)
Implicit network behavior (link previews, auto-fetches, thumbnail generation triggered by remote data)
Native code / FFI boundaries (C interop, JNI, ctypes, unsafe blocks, bridging headers)

For each flow found, note the relevant files and trace data from input to processing to output.

Read references/analysis-guide.md for detailed guidance by application type and platform.

Step 3: Write the Threat Model

Write to .turbo/threat-model.md (create .turbo/ if needed). The document has exactly four sections. Adapt depth to the codebase: a small CLI tool needs less detail than a multi-component crypto system.

Section 1: Overview

Write 1-2 paragraphs covering:

What the software is, its deployment model, and high-level architecture with key components (reference source paths)
Security-sensitive flows as a bulleted list (3-5 items, one sentence each)
What this repo owns versus what it delegates, and where the largest risks concentrate

For codebases with unique security properties (zero-knowledge design, client-side crypto, opportunistic encryption), call them out explicitly.

Section 2: Threat Model, Trust Boundaries and Assumptions

Assets: What has value to an attacker. Be specific: name data types, key material, tokens, metadata. Group naturally (user data, secrets, integrity artifacts).

Trust boundaries: Where trust levels change. Each boundary gets a bold name, a colon, 1-2 sentences explaining what crosses it, and a parenthetical code reference. Typical boundaries: untrusted storage/network, local OS/filesystem, IPC, admin configuration, identity provider, database.

Inputs by control tier:

Attacker-controlled: Data from untrusted sources that the software parses. For libraries, include data passed through the API from untrusted origins. Reference specific entry points.
Operator-controlled: Configuration, credentials, deployment parameters. Trusted but can be misconfigured.
Developer-controlled: Build scripts, dependency versions, test fixtures, debug-only behavior. The supply chain boundary.

Assumptions: Explicit statements about what must be true for the security model to hold. Include environmental assumptions (OS isolation, entropy sources), dependency assumptions (crypto library correctness), and operational assumptions (caller protects passwords). 2-4 bullets.

Section 3: Attack Surface, Mitigations and Attacker Stories

Organize into subsections by attack surface area (not by STRIDE category or component). Each subsection follows this structure:

### [3.N] [Surface Name]
**Surface**: What is exposed and where (1-2 sentences with file references).

**Entry points and sinks**
- `path:line` (untrusted input) → `path:line` (dangerous operation): what enters and what it reaches. When a surface has no code-level entry point, or nothing dangerous behind it, say so here.

**Hot files**
- `path` (1-3 files whose logic concentrates this surface, beyond the lines cited above)

**Mitigations**
- What the code already does to defend this surface (observations, not recommendations).

**Attacker stories**
- Concrete scenario: "[Attacker type] does [action] to [goal]: [consequence and severity context]."

Decomposition heuristic: One surface per distinct trust boundary crossing or distinct attacker capability. If two areas share the same entry points AND mitigations, merge them. If a single surface needs more than 3-4 unrelated risk/mitigation pairs, split it. Typical range: 4-9 surfaces.

For each surface, document:

1-2 sentence surface description with file references
Each entry point paired to the sink it reaches, both as path:line, plus the Hot files a reviewer must read end-to-end. When a surface has no code-level entry point or nothing dangerous behind it, say so rather than listing an empty field
2-4 mitigation bullets describing existing defenses (what the code does, not what it should do)
2-3 attacker stories: one sentence each, naming attacker type, action, and consequence

End section 3 with: A brief note on vulnerability classes that are less relevant for this application type, explaining why (e.g., "Web-specific issues like XSS and CSRF do not apply because this is a local library without network endpoints").

Section 4: Criticality Calibration

Group findings into four tiers. Each tier has 2-4 items, each a single sentence describing the impact (not the attack vector).

Critical: Remote exploitation compromising crown jewels or achieving code execution. Auth bypass, key/credential theft, RCE, cryptographic bypass.
High: Significant compromise requiring specific preconditions. Privilege escalation, targeted data theft, bypassing a major security control, integration compromise.
Medium: Real but limited impact or unlikely preconditions. Metadata leaks, DoS, policy bypass without data compromise, local data exposure.
Low: Theoretical, requires pre-compromised environment, or minimal impact. Verbose error messages, UI-only issues, log noise, debug-only risks.

Close with a calibration paragraph explaining how the application's deployment model and trust boundaries influence severity. For the attacker-position-vs-impact matrix and application-type adjustments, consult references/analysis-guide.md.

Step 4: Review

Before presenting the output, validate:

Codebase-specific: Every claim references actual files, modules, or architectural patterns. No generic filler.
Complete coverage: All security-sensitive flows from Step 2 appear in at least one attack surface, anchored by path:line in that surface's entry points or sinks.
Balanced mitigations: Each surface lists existing defenses. If none exist, state that explicitly.
Concrete stories: Each attacker story names a specific attacker, action, and consequence. No abstract "an attacker could exploit a vulnerability."
Consistent severity: Calibration in section 4 is consistent with severity context in section 3 stories.
Appropriate scope: Dependencies are acknowledged with assumptions, not audited internally. Integration boundaries are analyzed.
Out-of-scope declared: Irrelevant vulnerability classes are named and dismissed with reasons.

Fix any gaps, then present the threat model to the user.

Rules

Ground every claim in code. Reference specific classes, functions, or file paths. Do not speculate about code you have not read.
When a mitigation is absent, say so explicitly. Do not invent mitigations.
Do not audit the internals of external dependencies. Analyze the integration boundary only.
Adapt depth to the project. A 500-line CLI tool does not need the same depth as a cryptographic filesystem library.
The threat model is the only output. Do not create code, fix vulnerabilities, or modify the codebase.
Use ## for the four top-level sections (numbered 1-4), ### for attack surface subsections, and **bold** for sub-headings within subsections.
If the codebase has no meaningful security surface (no crypto, no auth, no network, no untrusted input), produce a brief threat model stating this with rationale, covering only dependency and supply-chain risks.

Files (turbo)

references

analysis-guide.md 12.6 KB

# Analysis Guide

Detailed guidance for analyzing different application types, platforms, and special concerns. Read the section relevant to your codebase.

## Contents
- Application type lenses
- Platform-specific considerations
- Protocol implementations
- Native code / FFI boundaries
- Implicit network behavior
- Cryptographic code
- Dependency boundary analysis
- STRIDE completeness check
- Severity calibration by context

## Application Type Lenses

The application type determines which attack surfaces to prioritize. Apply the relevant lens after identifying the codebase type.

### Web Service / API

Focus areas:
- **Authentication flow**: OIDC, sessions, API keys, token lifecycle, token storage
- **Authorization enforcement**: per-route, per-resource, role-based checks. Missing or incorrect annotations on new endpoints are critical.
- **Input validation**: every API boundary — path params, query params, JSON bodies, headers, file uploads
- **Injection**: SQL (parameterized queries?), NoSQL, command injection, template injection
- **Client-side security**: CSP, XSS prevention (template auto-escaping, no raw HTML rendering), CSRF resistance, cookie flags
- **SSRF**: any place where user input influences outbound requests (URLs, hostnames, redirect targets)
- **External integrations**: HTTP clients calling third-party services, secret management for API keys
- **Deployment security**: security headers, CORS, TLS termination, dev/prod separation, debug endpoints
- **Rate limiting and availability**: explicit rate limiting or reliance on infrastructure

XSS severity depends on what can be stolen: if browser-stored crypto keys or auth tokens are accessible, XSS is critical.

### Desktop Application

Focus areas:
- **File handling**: path validation, symlink following, temp file creation, permissions
- **Credential and key storage**: OS keychain usage, memory handling, zeroization
- **IPC**: named pipes, Unix domain sockets, shared memory, clipboard
- **Update mechanism**: signature verification, TLS, rollback protection
- **Mounting / filesystem exposure**: what is accessible when a vault/volume is mounted, interface binding (loopback vs all interfaces)
- **Plugin/extension loading**: ServiceLoader, dynamic imports, plugin directories with full app privileges
- **Local attack surface**: malicious files opened by the app, crafted configuration, environment variables

Severity adjustment: local attacker risks are typically lower than remote because local access often implies broader compromise.

### Library / SDK

Focus areas:
- **Public API surface**: what functions are exported, what inputs they accept, what invariants they maintain
- **Default security posture**: are defaults safe? Dangerous options should require explicit opt-in.
- **API misuse scenarios**: how can callers defeat the library's protections by using the API incorrectly? Rate misuse severity by how easy the mistake is AND how severe the consequences are. A footgun behind an explicit flag is less severe than a dangerous default.
- **Error handling**: do errors leak sensitive information? Are they distinguishable in ways that enable oracles?
- **Extension points**: ServiceLoader, plugin APIs, callback registration — what happens if an attacker controls these?
- **Dependency trust**: what does the library assume about its own dependencies?

Key principle: for libraries, the API surface IS the primary trust boundary. The three-tier input classification (attacker/operator/developer) is essential because the library cannot enforce how callers use it.

### CLI Tool

Focus areas:
- **Argument and stdin parsing**: injection risks, shell metacharacters
- **Filesystem interactions**: path traversal, race conditions (TOCTOU), symlink following
- **Environment variable handling**: secrets in env, PATH manipulation
- **Output handling**: secrets in stdout/stderr, piped to untrusted destinations
- **Privilege requirements**: does it need elevated privileges? How does it drop them?
- **Installer/setup**: privilege escalation during installation, fixed vs user-controlled paths

### Mobile Application

Focus areas:
- **Data at rest**: is local storage encrypted? SharedPreferences vs Keystore (Android), UserDefaults vs Keychain (iOS)
- **IPC**: intents, URL schemes, deep links, content providers, broadcast receivers
- **Certificate pinning**: custom TLS validation, ATS exceptions
- **Exported components**: activities, services, receivers marked as exported (Android)
- **Biometric auth bypass**: can biometric checks be skipped by modifying local state?
- **Clipboard and screenshot exposure**: does the app expose sensitive data through clipboard or allow screenshots of sensitive screens?

## Platform-Specific Considerations

Detect the platform from build files and framework imports, then apply the relevant lens.

### macOS / iOS
- **Sandbox status**: check entitlements for `com.apple.security.app-sandbox`. An unsandboxed app has wider blast radius.
- **Keychain usage**: prefer Keychain over file-based credential storage
- **App Transport Security**: check for HTTP exceptions in Info.plist
- **Hardened Runtime / code signing**: check entitlements
- **XPC services**: trust boundaries between XPC components
- **Sparkle / update mechanisms**: update feed integrity, signature verification

### Android
- **Exported components**: check AndroidManifest.xml for `exported="true"` on activities, services, receivers, providers
- **Permission model**: runtime vs install-time permissions, dangerous permissions
- **Android Keystore vs SharedPreferences**: secrets should use Keystore
- **WebView**: JavaScript bridge exposure, loadUrl with untrusted input
- **Intent handling**: validate incoming intents, check for intent redirection

### Server / Linux
- **Privilege level**: running as root vs unprivileged user, Linux capabilities
- **Container isolation**: namespace boundaries, mounted volumes, network policies
- **Filesystem permissions**: sensitive files (credentials, keys) should be 0600/0640
- **Systemd socket activation**: exposed ports, binding addresses

### Web / Electron
- **Origin model**: same-origin policy, CSP configuration
- **Node integration** (Electron): is Node.js accessible from renderer? `nodeIntegration`, `contextIsolation` settings
- **Cookie security**: HttpOnly, Secure, SameSite flags
- **CORS policy**: overly permissive origins

## Protocol Implementations

When the codebase implements or speaks a network protocol:

1. **Map the protocol stack layer by layer**: transport → framing → authentication → application messages. Each layer that processes attacker-controlled input before higher layers validate it is a potential attack surface.

2. **Flag these patterns**:
   - Opportunistic encryption (STARTTLS-style "upgrade if available") — always a downgrade risk
   - Server-provided URLs or redirect targets used without validation
   - Peer-to-peer negotiation where either side's parameters control the connection
   - Any place where a remote party's response changes the security properties of the session
   - Protocol version negotiation with fallback to weaker versions

3. **State machines**: connection lifecycle management (handshake → upgrade → auth → steady-state). Look for states where security properties are not yet established, but data is already processed.

## Native Code / FFI Boundaries

Search for FFI boundaries. The blast radius of bugs in native code is higher (memory corruption, not just logic errors).

**How to find them:**
- Swift: `import` of C modules, bridging headers, `UnsafePointer`/`UnsafeBufferPointer`, `withUnsafe*` closures
- Kotlin/JVM: JNI, `System.loadLibrary`, native method declarations
- Python: `ctypes`, `cffi`, Cython `.pyx` files, C extension modules
- Rust: `unsafe` blocks wrapping FFI calls, `extern "C"` blocks
- Node.js: native addons (`.node`), `node-gyp` config, N-API

**For each FFI boundary, assess:**
- Is the native library processing untrusted input? (If yes, this is a significant attack surface)
- Are safety features configured? (Entity expansion limits, buffer size caps, sandboxing)
- Do callers validate inputs before passing them to native code?
- What is the native library's general CVE history? (Note as risk factor)

## Implicit Network Behavior

Trace every path from "remote data arrives" to "outbound network request is made." Any path without an explicit user consent gate is an attack surface.

**Common patterns:**
- URL extraction from messages that triggers automatic metadata/preview fetches
- Framework auto-fetch behavior (LPMetadataProvider, AsyncImage, OEmbed, OpenGraph resolvers)
- Avatar/profile picture loading from user-provided URLs
- DNS lookups triggered by untrusted hostnames (SRV records, MX lookups)
- Webhook/callback URLs where a remote party specifies where the app sends data

**Assess for each:**
- IP disclosure to attacker-controlled servers
- SSRF potential (can it hit localhost or internal services?)
- Volume/DoS (can one message trigger many fetches?)
- Scheme restriction (limited to HTTPS, or can `file://`, `ftp://` be triggered?)

## Cryptographic Code

When the codebase performs cryptographic operations:

1. **Map the key hierarchy**: master key → derived keys → per-operation keys. Note how key material flows and where blast radius is limited.

2. **Trace nonce/IV management**: nonce reuse in AES-GCM or AES-CTR is catastrophic. Verify nonces come from a strong source and are never reused.

3. **Check authentication**: is authenticated encryption used (AES-GCM, ChaCha20-Poly1305)? Are MAC comparisons constant-time? Can authentication be skipped via API flags?

4. **Assess key protection**: how are keys stored at rest? Scrypt/Argon2 parameters for password-derived keys? Key zeroization after use?

5. **Identify designed leakage**: deterministic encryption leaks equality. Chunked encryption leaks file size. Note these as inherent properties, not bugs.

6. **Side-channel awareness**: constant-time comparisons for secrets, memory zeroization attempts, RNG quality.

Do not perform deep novel cryptanalysis. Identify which primitives are used, verify they are applied correctly for their guarantees, and flag known dangerous patterns.

## Dependency Boundary Analysis

When the codebase delegates security-critical operations to an external library:

1. **State the trust assumption**: name the dependency and what it is trusted to do. Example: "cryptolib implements authenticated encryption and key handling correctly."

2. **Analyze the integration boundary**: does this codebase pass correct inputs? Handle error returns? Avoid misuse patterns (nonce reuse, ignoring auth failures)?

3. **Do not audit the dependency's internals**. Focus on how this codebase uses it.

4. **Flag unverified assumptions**: when the assumption is hard to verify (e.g., "SecureRandom is strong and available"), note conditions under which it could fail.

## STRIDE Completeness Check

After drafting the threat model, verify coverage against STRIDE. You do not need to organize by STRIDE, but every applicable category should appear somewhere:

- **Spoofing**: Can an attacker impersonate a user, service, or component?
- **Tampering**: Can an attacker modify data in transit or at rest?
- **Repudiation**: Can actions be performed without accountability?
- **Information disclosure**: Can secrets, data, or metadata leak?
- **Denial of service**: Can availability be degraded?
- **Elevation of privilege**: Can an attacker gain capabilities beyond their trust level?

If a category is not represented in the threat model, either add coverage or note it in the "less relevant" paragraph with a reason.

## Severity Calibration by Context

Severity depends on the intersection of attacker position and impact:

| Impact | Remote Unauth | Remote Auth | Local Unpriv | Local Admin |
|---|---|---|---|---|
| Key/secret compromise | Critical | Critical | High | Medium |
| Code execution | Critical | Critical | High | Medium |
| Bulk data exposure | Critical | High | Medium | Low |
| Limited data exposure | High | Medium | Low | Low |
| Denial of service | Medium | Medium | Low | Low |
| Metadata leakage | Medium | Low | Low | Low |

**Adjustments by application type:**
- **Web services**: remote unauthenticated attacks weight highest. XSS is critical when it can steal crypto keys or auth tokens.
- **Desktop apps**: account for the local attacker model (lower baseline). Issues requiring OS-level compromise are medium at most.
- **Libraries**: rate severity relative to the worst realistic caller context. Unsafe defaults affect every consumer.
- **Mobile apps**: consider the device theft model. Data at rest severity depends on encryption status.

Always explain the calibration rationale in section 4. Generic CVSS-style scoring without context is not useful.

SKILL.md 9.9 KB

---
name: create-threat-model
description: "Analyze a codebase and produce a structured threat model at .turbo/threat-model.md covering assets, trust boundaries, attack surfaces with existing mitigations, attacker stories, and calibrated severity. Use when the user asks to \"create a threat model\", \"threat model\", \"threat model this codebase\", \"security analysis\", \"analyze the attack surface\", \"what are the threats\", or \"identify security risks\"."
---

# Create Threat Model

Analyze the current codebase and produce a structured threat model at `.turbo/threat-model.md`.

The threat model describes the current state of the codebase: what it protects, where trust boundaries are, how it can be attacked, what defenses exist, and how severe each risk is. It is descriptive, not prescriptive. Do not include remediation recommendations.

Optional: `$ARGUMENTS` may specify scope (directories, modules, or focus areas). When scope is provided, limit reconnaissance and code discovery to the specified directories or modules. Still produce all four sections, but title the overview to reflect the narrowed scope and note what is excluded.

## Step 1: Reconnaissance

Build a mental model of the system before analyzing threats.

1. Read the project README, CLAUDE.md, and any architecture or security documentation.
2. Examine top-level directory structure, build files, and dependency manifests to identify modules, languages, frameworks, and deployment model.
3. **Classify the application type**: library, CLI tool, web service, desktop app, mobile app, or hybrid. This determines which threat categories and trust boundary patterns apply.
4. Identify security-critical dependencies (crypto libraries, auth providers, network stacks, native/FFI libraries). Note what this codebase delegates versus what it owns.
5. Read any existing security documentation: `SECURITY.md`, audit reports, threat models, or changelog entries mentioning CVEs.

## Step 2: Security-Relevant Code Discovery

Search the codebase for code that handles security-sensitive operations. Do not read every file. Use targeted searches.

**Categories to search for:**
- Authentication and authorization (login, OAuth, tokens, sessions, RBAC, API keys)
- Cryptographic operations (encryption, signing, hashing, key generation, key derivation)
- Secret and credential storage (keychains, vaults, env vars, config files with secrets)
- Network communication (HTTP clients, TLS configuration, certificate handling, WebSocket, gRPC)
- Untrusted input processing (file parsing, deserialization, XML/JSON/YAML from external sources)
- IPC and process boundaries (sockets, pipes, CLI subprocesses, shared memory)
- Plugin and extension loading (dynamic imports, ServiceLoader, plugin directories)
- Update and distribution mechanisms (auto-update, download verification, signature checking)
- Implicit network behavior (link previews, auto-fetches, thumbnail generation triggered by remote data)
- Native code / FFI boundaries (C interop, JNI, ctypes, unsafe blocks, bridging headers)

For each flow found, note the relevant files and trace data from input to processing to output.

Read [references/analysis-guide.md](references/analysis-guide.md) for detailed guidance by application type and platform.

## Step 3: Write the Threat Model

Write to `.turbo/threat-model.md` (create `.turbo/` if needed). The document has exactly four sections. Adapt depth to the codebase: a small CLI tool needs less detail than a multi-component crypto system.

### Section 1: Overview

Write 1-2 paragraphs covering:
- What the software is, its deployment model, and high-level architecture with key components (reference source paths)
- Security-sensitive flows as a bulleted list (3-5 items, one sentence each)
- What this repo owns versus what it delegates, and where the largest risks concentrate

For codebases with unique security properties (zero-knowledge design, client-side crypto, opportunistic encryption), call them out explicitly.

### Section 2: Threat Model, Trust Boundaries and Assumptions

**Assets**: What has value to an attacker. Be specific: name data types, key material, tokens, metadata. Group naturally (user data, secrets, integrity artifacts).

**Trust boundaries**: Where trust levels change. Each boundary gets a **bold name**, a colon, 1-2 sentences explaining what crosses it, and a parenthetical code reference. Typical boundaries: untrusted storage/network, local OS/filesystem, IPC, admin configuration, identity provider, database.

**Inputs by control tier**:
- **Attacker-controlled**: Data from untrusted sources that the software parses. For libraries, include data passed through the API from untrusted origins. Reference specific entry points.
- **Operator-controlled**: Configuration, credentials, deployment parameters. Trusted but can be misconfigured.
- **Developer-controlled**: Build scripts, dependency versions, test fixtures, debug-only behavior. The supply chain boundary.

**Assumptions**: Explicit statements about what must be true for the security model to hold. Include environmental assumptions (OS isolation, entropy sources), dependency assumptions (crypto library correctness), and operational assumptions (caller protects passwords). 2-4 bullets.

### Section 3: Attack Surface, Mitigations and Attacker Stories

Organize into subsections by attack surface area (not by STRIDE category or component). Each subsection follows this structure:

```
### [3.N] [Surface Name]
**Surface**: What is exposed and where (1-2 sentences with file references).

**Entry points and sinks**
- `path:line` (untrusted input) → `path:line` (dangerous operation): what enters and what it reaches. When a surface has no code-level entry point, or nothing dangerous behind it, say so here.

**Hot files**
- `path` (1-3 files whose logic concentrates this surface, beyond the lines cited above)

**Mitigations**
- What the code already does to defend this surface (observations, not recommendations).

**Attacker stories**
- Concrete scenario: "[Attacker type] does [action] to [goal]: [consequence and severity context]."
```

**Decomposition heuristic**: One surface per distinct trust boundary crossing or distinct attacker capability. If two areas share the same entry points AND mitigations, merge them. If a single surface needs more than 3-4 unrelated risk/mitigation pairs, split it. Typical range: 4-9 surfaces.

**For each surface, document**:
- 1-2 sentence surface description with file references
- Each entry point paired to the sink it reaches, both as `path:line`, plus the Hot files a reviewer must read end-to-end. When a surface has no code-level entry point or nothing dangerous behind it, say so rather than listing an empty field
- 2-4 mitigation bullets describing existing defenses (what the code does, not what it should do)
- 2-3 attacker stories: one sentence each, naming attacker type, action, and consequence

**End section 3 with**: A brief note on vulnerability classes that are less relevant for this application type, explaining why (e.g., "Web-specific issues like XSS and CSRF do not apply because this is a local library without network endpoints").

### Section 4: Criticality Calibration

Group findings into four tiers. Each tier has 2-4 items, each a single sentence describing the **impact** (not the attack vector).

- **Critical**: Remote exploitation compromising crown jewels or achieving code execution. Auth bypass, key/credential theft, RCE, cryptographic bypass.
- **High**: Significant compromise requiring specific preconditions. Privilege escalation, targeted data theft, bypassing a major security control, integration compromise.
- **Medium**: Real but limited impact or unlikely preconditions. Metadata leaks, DoS, policy bypass without data compromise, local data exposure.
- **Low**: Theoretical, requires pre-compromised environment, or minimal impact. Verbose error messages, UI-only issues, log noise, debug-only risks.

Close with a calibration paragraph explaining how the application's deployment model and trust boundaries influence severity. For the attacker-position-vs-impact matrix and application-type adjustments, consult [references/analysis-guide.md](references/analysis-guide.md).

## Step 4: Review

Before presenting the output, validate:

1. **Codebase-specific**: Every claim references actual files, modules, or architectural patterns. No generic filler.
2. **Complete coverage**: All security-sensitive flows from Step 2 appear in at least one attack surface, anchored by `path:line` in that surface's entry points or sinks.
3. **Balanced mitigations**: Each surface lists existing defenses. If none exist, state that explicitly.
4. **Concrete stories**: Each attacker story names a specific attacker, action, and consequence. No abstract "an attacker could exploit a vulnerability."
5. **Consistent severity**: Calibration in section 4 is consistent with severity context in section 3 stories.
6. **Appropriate scope**: Dependencies are acknowledged with assumptions, not audited internally. Integration boundaries are analyzed.
7. **Out-of-scope declared**: Irrelevant vulnerability classes are named and dismissed with reasons.

Fix any gaps, then present the threat model to the user.

## Rules

- Ground every claim in code. Reference specific classes, functions, or file paths. Do not speculate about code you have not read.
- When a mitigation is absent, say so explicitly. Do not invent mitigations.
- Do not audit the internals of external dependencies. Analyze the integration boundary only.
- Adapt depth to the project. A 500-line CLI tool does not need the same depth as a cryptographic filesystem library.
- The threat model is the only output. Do not create code, fix vulnerabilities, or modify the codebase.
- Use `##` for the four top-level sections (numbered 1-4), `###` for attack surface subsections, and `**bold**` for sub-headings within subsections.
- If the codebase has no meaningful security surface (no crypto, no auth, no network, no untrusted input), produce a brief threat model stating this with rationale, covering only dependency and supply-chain risks.