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

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

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