threat-modellisted

# 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 combina