Threat Modeling

Purpose

Provide systematic methodology for identifying security threats through technology decomposition, data flow analysis, and STRIDE-based threat enumeration. This skill helps transform architectural understanding into actionable security findings.

Key Insight: Threat modeling answers "What could go wrong?" systematically. It bridges the gap between understanding an application and hunting for vulnerabilities.

When to Use

Activate this skill when:

• After running /vuln-scout:threats --quick to understand the app
• Before targeted sink searching (to prioritize what to look for)
• When analyzing a new component or service
• To create visual data flow diagrams
• When systematically enumerating threats per component
• To score and prioritize security risks

STRIDE Methodology

STRIDE is a threat classification framework. For each component, analyze:

Threat Modeling Workflow

Phase 1: Technology Decomposition

Break down the application into components:

1. Entry Points (where data enters)
   - HTTP endpoints, WebSocket, file uploads, API integrations

2. Processing Components (where data transforms)
   - Controllers, services, background jobs, validators

3. Data Stores (where data persists)
   - Databases, caches, file systems, queues

4. External Dependencies (what system trusts)
   - Third-party APIs, OAuth providers, CDN

5. Security Components (what protects)
   - Authentication, authorization, encryption, validation

Phase 2: Data Flow Mapping

Trace how data moves through the system:

[Entry Point] → [Validation?] → [Processing] → [Storage]
                     ↓
              [Trust Boundary]

For each flow, document:

• What data crosses each boundary?
• Where is validation performed?
• What assumptions exist?
• Where is data encrypted/decrypted?

Phase 3: STRIDE Analysis Per Component

For each component identified, apply STRIDE:

## Component: Authentication Service

| Threat | Category | Risk | Location |
|--------|----------|------|----------|
| Password spraying | Spoofing | HIGH | routes/login.ts |
| JWT secret in code | Info Disclosure | CRITICAL | lib/auth.ts |
| No rate limiting | DoS | MEDIUM | middleware/auth.ts |
| Role in JWT editable | Elevation | HIGH | lib/token.ts |

Phase 4: Prioritization

Score threats by:

1. Impact (1-5): What's the damage if exploited?
2. Likelihood (1-5): How easy is exploitation?
3. Risk Score = Impact × Likelihood

Priority order:

• CRITICAL (20-25): Immediate attention
• HIGH (15-19): Next sprint
• MEDIUM (8-14): Backlog
• LOW (1-7): Accept or defer

Data Flow Diagrams (Mermaid)

Basic Application Flow

flowchart TB
    subgraph External["External (Untrusted)"]
        User([User Browser])
        Mobile([Mobile App])
        ExtAPI([3rd Party API])
    end

    subgraph DMZ["DMZ"]
        LB[Load Balancer]
        WAF[WAF]
    end

    subgraph Application["Application (Trusted)"]
        API[API Server]
        Auth[Auth Service]
        Worker[Background Worker]
    end

    subgraph Data["Data Layer"]
        DB[(Primary DB)]
        Cache[(Redis Cache)]
        Queue[(Message Queue)]
    end

    User -->|HTTPS| LB
    Mobile -->|HTTPS| LB
    LB --> WAF
    WAF --> API
    API <-->|JWT| Auth
    API --> DB
    API --> Cache
    API --> Queue
    Queue --> Worker
    Worker --> DB
    API <-->|HTTPS| ExtAPI

Trust Boundary Diagram

flowchart LR
    subgraph Untrusted["Untrusted Zone"]
        Input([User Input])
    end

    subgraph TB1["Trust Boundary 1"]
        direction TB
        Validate[Input Validation]
    end

    subgraph Trusted["Trusted Zone"]
        Process[Business Logic]
        Store[(Database)]
    end

    Input -->|"raw data"| Validate
    Validate -->|"validated data"| Process
    Process -->|"queries"| Store

    style TB1 stroke:#ff0000,stroke-width:2px

Authentication Flow

sequenceDiagram
    participant U as User
    participant A as API
    participant Auth as Auth Service
    participant DB as Database

    U->>A: POST /login (creds)
    A->>Auth: Validate credentials
    Auth->>DB: Check user
    DB-->>Auth: User data
    Auth-->>A: JWT token
    A-->>U: Set-Cookie / Token

    Note over A,Auth: Trust boundary - validate token signature

Component-Specific Threats

API Endpoints

Authentication Components

File Upload Handlers

Database Access

External API Integrations

Code Review Patterns

Finding Components to Analyze

# Find route definitions (entry points)
grep -rniE "(app\.(get|post|put|delete)|@(Get|Post|Route)|router\.)" --include="*.ts" --include="*.js"

# Find database models (data stores)
grep -rniE "(Schema|Model|Entity|Table)" --include="*.ts" --include="*.js" --include="*.py"

# Find external API calls
grep -rniE "(fetch|axios|requests\.|http\.)" --include="*.ts" --include="*.js" --include="*.py"

# Find auth/security middleware
grep -rniE "(auth|security|jwt|session|token)" --include="*.ts" --include="*.js" --include="*.py"

STRIDE-Specific Searches

# Spoofing - weak auth
grep -rniE "(algorithm|alg|HS256|none)" --include="*.ts" --include="*.js"

# Tampering - user input in dangerous ops
grep -rniE "(query|exec|eval|execute).*req\.(body|query|params)" --include="*.ts" --include="*.js"

# Info Disclosure - sensitive data exposure
grep -rniE "(password|secret|key|token).*log" --include="*.ts" --include="*.js"

# DoS - missing limits
grep -rniE "(upload|file|size|limit)" --include="*.ts" --include="*.js"

# Elevation - role/permission
grep -rniE "(role|admin|permission|isAdmin)" --include="*.ts" --include="*.js"

Output Templates

Threat Model Summary

# Threat Mo