threat-model

Threat Model — Attack Surface Analysis

Iron Law

Every system has an attack surface. If you haven't identified it, you haven't secured it.

Process

Step 0: Load Engagement Context

Check for .harness/engagement.md in the project root. If present, load the scope (in-scope/out-of-scope) and constraints. Skip threat modeling for explicitly out-of-scope components.

Without engagement context, proceed with full-surface analysis.

Step 1: Identify Trust Boundaries

Map every boundary where data crosses a trust level:

1. External → Internal: API endpoints, webhooks, file uploads, user input
2. Internal → Privileged: DB queries, file system access, shell execution
3. Service → Service: Inter-service communication, message queues, shared state
4. Client → Server: Auth tokens, session state, CORS origins

For each boundary, document:

• Data flow direction
• Input validation present (yes/no/partial)
• Authentication required (yes/no)
• Encryption in transit (yes/no)

Step 2: Enumerate Threat Actors

| Actor | Motivation | Capability | Target |

|-------|-----------|------------|--------|

| Anonymous user | Exploration | Low | Public endpoints |

| Authenticated user | Data access | Medium | Own data + IDOR targets |

| Malicious insider | Data exfiltration | High | All internal systems |

| Compromised dependency | Supply chain | Variable | Build/deploy pipeline |

Step 3: Generate Threat Scenarios

For each trust boundary × threat actor combination, generate:

1. Attack vector: How the boundary is crossed maliciously
2. Impact: What is compromised (CIA triad — Confidentiality, Integrity, Availability)
3. Likelihood: High/Medium/Low based on exposure and complexity
4. Existing mitigations: What already prevents this
5. Gap: What is missing

Step 4: Produce Output

Write THREAT_MODEL.md:

# Threat Model — {project}

## Scope
- In-scope: {from engagement.md or full codebase}
- Out-of-scope: {from engagement.md or none}
- Date: {ISO date}

## Trust Boundaries
| # | Boundary | Direction | Validation | Auth | Encryption |
|---|----------|-----------|------------|------|------------|
| 1 | ... | ... | ... | ... | ... |

## Threat Scenarios
| ID | Boundary | Actor | Vector | Impact | Likelihood | Mitigated | Gap |
|----|----------|-------|--------|--------|------------|-----------|-----|
| T1 | ... | ... | ... | ... | ... | Partial | ... |

## Priority Remediation
1. [CRITICAL] {highest risk gap}
2. [HIGH] {next gap}
3. [MEDIUM] {remaining gaps}

## Assumptions
- {list all assumptions made during analysis}

Step 5: Feed into vuln-scan

After producing the threat model, suggest:

"Run /vuln-scan to validate threat scenarios against the codebase."

Anti-Rationalization

| Excuse | Rebuttal | What to do instead |

|--------|----------|-------------------|

| "We don't have any external-facing components" | Internal trust boundaries are attack surfaces too. Lateral movement starts inside. | Model internal boundaries with the same rigor. |

| "Threat modeling is overkill for a small project" | Small projects get breached too. The model is proportional to the codebase. | Run the process. It takes 10 minutes. A breach takes months. |

| "We already have a threat model" | Threat models expire. Every code change can invalidate assumptions. | Update the model when significant changes land. |

| "The framework handles security" | Frameworks don't model YOUR business logic threats. | Add application-layer threat scenarios on top of framework defaults. |

Evidence Required

• [ ] Every trust boundary in the codebase identified
• [ ] At least 2 threat scenarios per boundary
• [ ] Each scenario has impact, likelihood, and gap assessment
• [ ] Priority remediation list ordered by risk
• [ ] Assumptions explicitly listed (not hidden)

Red Flags

• Skipping boundaries because they're "internal"
• Listing only one threat scenario per boundary
• Marking all scenarios as "already mitigated" without evidence
• No assumptions section — means assumptions are hidden, not absent
• Threat model that doesn't reference actual code paths