/threats

name: threats
description: "[beta] Application understanding + threat modeling - maps architecture, generates DFDs, performs STRIDE analysis"
argument-hint: "[--scope name] [--save filename.md] [--quick] [--diagram-only] [--stride-only]"
allowed-tools:
  - Glob
  - Grep
  - Read
  - Write
  - TodoWrite
  - Task

Threat Modeling Workflow

Combines application understanding with systematic threat identification. First understands the application, then identifies what could go wrong.

Philosophy

> "Understanding the application deeply will always beat automation." - NahamSec

Before searching for sinks, understand:

• What does this application do?
• Who are the users and what can they do?
• Where does trust exist between components?
• What workflows involve sensitive operations?

---

Flags

| Flag | Effect | |------|--------| | `--quick` | Quick understanding only (skip STRIDE, faster) | | `--diagram-only` | Only generate data flow diagrams | | `--stride-only` | Skip understanding, go straight to STRIDE | | `--scope name` | Use pre-created scope file | | `--save file.md` | Save output to file |

---

Initial Setup

1. Create a todo list to track progress 2. If `--quick` flag: do Phase 1 only (app understanding) 3. If `--diagram-only` flag: skip to Phase 2 (Data Flow Diagramming) 4. If `--stride-only` flag: skip to Phase 3 (STRIDE Analysis)

---

Scoping Support

Using with Compressed Scope (Large Codebases)

For large codebases (>300k tokens), run architecture-level threat modeling on a compressed scope:

# First create compressed scope
/vuln-scout:scope . --compress --name architecture

# Then run threats on the scope
/vuln-scout:threats --scope architecture --save .claude/threat-model.md

If `--scope` provided:

1. Load scope file from `.claude/scope-[name].md` 2. Generate **system-level** DFDs and trust boundaries (not function-level) 3. Perform STRIDE on **components** (services, modules, data stores) not individual functions 4. Focus on:

• Inter-module communication patterns
• Trust boundary crossings between modules
• External integration points
• Data flow between major components

5. Output serves as **context for module-level audits**

System-Level vs Function-Level Threat Modeling

| Aspect | Compressed (System-Level) | Full Code (Function-Level) | |--------|---------------------------|---------------------------| | Scope | Entire codebase | Single module | | Components | Services, modules, data stores | Functions, methods, classes | | Threats | Architecture flaws, trust issues | Implementation bugs, injection points | | DFDs | High-level data flow | Detailed source-to-sink | | Use case | Initial threat landscape | Deep vulnerability hunting |

Workflow Integration

The threat model generated here is automatically loaded by `/vuln-scout:full-audit` when analyzing individual modules:

# Phase 1: Create system threat model (once)
/vuln-scout:threats --scope architecture --save .claude/threat-model.md

# Phase 2: Module audits reference this context
/vuln-scout:full-audit --scope impl
# ^ Shows relevant threats from system model for this module

---

Phase 1: Technology Decomposition

Step 1.1: Identify Entry Points

Search for all places where data enters the system:

# HTTP endpoints
grep -rniE "(app\.(get|post|put|delete|patch)|@(Get|Post|Put|Delete|Patch|RequestMapping)|router\.(get|post))" --include="*.ts" --include="*.js" --include="*.java" --include="*.py"

# WebSocket handlers
grep -rniE "(ws\.|websocket|socket\.on|@OnMessage)" --include="*.ts" --include="*.js" --include="*.java"

# File upload handlers
grep -rniE "(multer|upload|multipart|@RequestPart|FileUpload)" --include="*.ts" --include="*.js" --include="*.java" --include="*.py"

# GraphQL resolvers
grep -rniE "(resolver|@Query|@Mutation|graphql)" --include="*.ts" --include="*.js"

# Browser Event Handlers (CRITICAL - often missed!)
grep -rniE "(addEventListener\s*\(\s*['\"]message['\"]|\.onmessage\s*=)" --include="*.js" --include="*.ts" --include="*.html"

# postMessage origin validation check
grep -rniE "addEventListener\s*\(\s*['\"]message['\"]" --include="*.js" --include="*.ts" -A 10 | grep -v "origin"

**IMPORTANT**: Browser event handlers like `addEventListener("message", ...)` are entry points for cross-origin data! Check for missing `event.origin` validation.

Document each entry point with:

• Route/endpoint path
• HTTP method
• Parameters accepted
• Authentication required?

Step 1.2: Identify Processing Components

Search for business logic components:

# Services/Controllers
grep -rniE "(Service|Controller|Handler|Manager|Processor)" --include="*.ts" --include="*.js" --include="*.java" --include="*.py"

# Middleware
grep -rniE "(middleware|interceptor|filter|@Before|@After)" --include="*.ts" --include="*.js" --include="*.java"

# Background workers
grep -rniE "(queue|worker|job|cron|scheduler|@Scheduled)" --include="*.ts" --include="*.js" --include="*.java" --include="*.py"

Step 1.3: Identify Data Stores

Search for persistence layers:

# Database connections
grep -rniE "(mongoose|sequelize|prisma|typeorm|knex|sqlalchemy|hibernate|activerecord)" --include="*.ts" --include="*.js" --include="*.java" --include="*.py" --include="*.rb"

# Cache systems
grep -rniE "(redis|memcached|cache|@Cacheable)" --include="*.ts" --include="*.js" --include="*.java" --include="*.py"

# File storage
grep -rniE "(s3|blob|storage|FileOutputStream|writeFile)" --include="*.ts" --include="*.js" --include="*.java" --include="*.py"

# Message queues
grep -rniE "(rabbitmq|kafka|sqs|pubsub|amqp)" --include="*.ts" --include="*.js" --include="*.java" --include="*.py"

Step 1.4: Identify External Dependencies

Search for third-party integrations:

# HTTP clients (external API calls)
grep -rniE "(axios|fetch|requests\.|HttpClient|RestTemplate)" --include="*.ts" --include="*.js" --include="*.java" --include=