Get the FREE Ultimate OpenClaw Setup Guide →

Threat Modeling

npx machina-cli add skill allsmog/vuln-scout/threat-modeling --openclaw
Files (1)
SKILL.md
9.4 KB

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 /whitebox-pentest: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:

CategoryQuestionExample Threat
SpoofingCan identity be faked?JWT algorithm confusion, session hijacking
TamperingCan data be modified?SQL injection, parameter manipulation
RepudiationCan actions be denied?Missing audit logs, unsigned transactions
Information DisclosureCan data leak?Error messages, log exposure, IDOR
Denial of ServiceCan it be overwhelmed?ReDoS, resource exhaustion, billion laughs
Elevation of PrivilegeCan access be escalated?Broken access control, role manipulation

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

ThreatSTRIDEIndicators
InjectionTamperingUser input in queries/commands
Broken authSpoofingMissing/weak authentication
IDORInfo DisclosureDirect object references
Mass assignmentTamperingFull object binding
No rate limitingDoSMissing throttling

Authentication Components

ThreatSTRIDEIndicators
Credential stuffingSpoofingNo account lockout
Session fixationSpoofingSession ID reuse
JWT vulnerabilitiesSpoofing/TamperingAlgorithm confusion, weak secret
Password storageInfo DisclosureWeak hashing (MD5, SHA1)

File Upload Handlers

ThreatSTRIDEIndicators
Path traversalTamperingUser-controlled filename
XXEInfo DisclosureXML parsing with entities
Unrestricted uploadElevationMissing type validation
DoS via large filesDoSNo size limits

Database Access

ThreatSTRIDEIndicators
SQL injectionTamperingString concatenation
NoSQL injectionTamperingOperator injection
Data exposureInfo DisclosureVerbose errors
Connection exposureInfo DisclosureCredentials in code/logs

External API Integrations

ThreatSTRIDEIndicators
SSRFTamperingUser-controlled URLs
Credential exposureInfo DisclosureAPI keys in code
Man-in-the-middleSpoofingNo TLS verification
Injection via responseTamperingUnsanitized API responses

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 Model: [Application Name]

## Overview
[Brief description of application and scope]

## Data Flow Diagram
[Mermaid diagram here]

## Trust Boundaries
1. **Client → API**: User input validation
2. **API → Database**: Query parameterization
3. **API → External Services**: Credential protection

## STRIDE Analysis

### Critical Threats
| ID | Component | Threat | Category | Risk | Location |
|----|-----------|--------|----------|------|----------|
| T-001 | Login | SQL Injection | Tampering | CRITICAL | routes/login.ts:34 |

### High Threats
[...]

## Recommended Mitigations
[...]

Integration with Other Skills

  • Use business-logic for workflow and trust boundary understanding
  • Use dangerous-functions to find sinks for identified threats
  • Use data-flow-tracing to trace specific threat paths
  • Use vuln-patterns for exploitation techniques
  • Use exploit-techniques to develop PoC for confirmed threats

Reference Files

For detailed threat patterns:

  • references/stride-by-component.md - Common threats per component type
  • references/common-threats-by-tech.md - Technology-specific threats
  • references/data-flow-patterns.md - Data flow vulnerability patterns

Source

git clone https://github.com/allsmog/vuln-scout/blob/main/whitebox-pentest/skills/threat-modeling/SKILL.mdView on GitHub

Overview

Provides a systematic methodology to identify security threats through technology decomposition, data flow analysis, and STRIDE-based threat enumeration. It turns architectural understanding into actionable findings and helps whitebox pentesters prioritize risks.

How This Skill Works

Breaks the app into components via technology decomposition, maps data flows, and identifies trust boundaries. Then, per component, STRIDE is applied to enumerate threats and a risk score is calculated to prioritize fixes.

When to Use It

  • After running /whitebox-pentest: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 and prioritizing risks

Quick Start

  1. Step 1: Decompose the system into Entry Points, Processing, Data Stores, External Dependencies, and Security Components
  2. Step 2: Map data flows and identify Trust Boundaries; note validation and encryption points
  3. Step 3: Apply STRIDE per component, capture threats, and compute a prioritized risk register

Best Practices

  • Start with technology decomposition: entry points, processing, data stores, external dependencies, and security components
  • Map data flows and clearly define trust boundaries for each flow
  • Apply STRIDE per component and document threats in a threat register
  • Quantify risk with Impact and Likelihood (1-5) and use a CRITICAL/HIGH/MEDIUM/LOW prioritization
  • Keep threat models aligned with architecture changes and automate artifact generation (DFDs, risk registers)

Example Use Cases

  • Threat model for a web app's authentication service focusing on STRIDE categories and session handling
  • Data flow diagram that traces user input from entry points to storage with trust boundaries
  • Threats per component such as Authentication Service, including password spraying, JWT exposure, and rate-limiting gaps
  • Prioritized remediation plan highlighting CRITICAL issues identified during STRIDE analysis
  • Security architecture review for a microservices SaaS platform with external dependencies and encryption requirements

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers