Create Threat Model

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, AGENTS.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 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").