threat-model

Threat Model

Produces structured, evidence-backed security threat models for any codebase. Goes beyond surface enumeration by tracing untrusted data through actual code paths, clustering findings by root cause, and constructing exploit chains that combine individual findings into higher-severity attack paths.

When to Apply

• User asks to threat model, security review, or map attack surfaces for a codebase
• Starting work on security-sensitive features (auth, crypto, file I/O, networking, native bridges)
• Evaluating a new codebase or major architectural change for security implications
• Reviewing a PR or recent commits for security regressions (incremental/diff mode)
• After a security incident to reassess the threat landscape

Workflow Overview

Phase 0 (conditional): Diff Analysis — if git range provided, scope to changed code
Phase 1:  Codebase Survey        → Understand what the project is and does
Phase 2:  Component Mapping      → Identify components, data flows, and language bridges
Phase 3:  Asset Identification   → Determine what needs protecting
Phase 4:  Trust Boundaries       → Classify inputs by trust level, inventory entry points
Phase 5:  Data Flow Tracing      → Follow untrusted values from entry to sink ← key technique
Phase 6:  Attack Surface Enum    → Document surfaces with traced evidence
Phase 7:  Pattern Clustering     → Group 3+ similar findings by root cause
Phase 8:  Exploit Chains         → Combine findings into multi-step attack paths
Phase 9:  Calibration            → Rate with chain-adjusted and systemic severity
Phase 10: Output                 → Write structured THREAT-MODEL.md

How to Use

1. Read methodology for the detailed approach at each phase
2. Read output format for the document structure (6 sections)
3. Consult attack patterns for technology-specific patterns
4. Run scripts/trace-data-flows.sh <project-root> to inventory entry points and sinks
5. Optionally run scripts/scan-patterns.sh <project-root> for security-relevant code patterns