/create-threat-model

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 recommendat