Threat Model Generation

Threat Model Generation

Generate a comprehensive security threat model for a repository using the STRIDE methodology. This skill analyzes the codebase architecture and produces an LLM-optimized threat model document that other security skills can reference.

When to Use This Skill

• First-time setup - New repository needs initial threat model
• Architecture changes - Significant changes to components, APIs, or data flows
• Security audit - Periodic review or compliance requirement
• Manual request - Security team requests updated threat model

Inputs

Before running this skill, gather or confirm:

Instructions

Follow these steps in order:

Step 1: Analyze Repository Structure

Scan the codebase to understand the system:

1. Identify languages and frameworks

• Check package.json, requirements.txt, go.mod, Cargo.toml, etc.
• Note the primary tech stack (e.g., Next.js, Django, Go microservices)

2. Map components and services

• Look for apps/, services/, packages/ directories
• Identify entry points: API routes, CLI commands, web handlers
• Note databases, caches, message queues

3. Identify external interfaces

• HTTP endpoints (REST, GraphQL)
• File upload handlers
• Webhook receivers
• OAuth/SSO integrations
• CLI commands that accept user input

4. Trace data flows

• How does user input enter the system?
• Where is sensitive data stored?
• What external services are called?

Step 2: Identify Trust Boundaries

Define security zones:

1. Public Zone (untrusted)

• All external HTTP endpoints
• Public APIs without authentication
• User-uploaded files

2. Authenticated Zone (partially trusted)

• Endpoints requiring valid session/token
• User-specific data access
• Rate-limited APIs

3. Internal Zone (trusted)

• Service-to-service communication
• Admin-only endpoints
• Database connections
• Secrets management

Document where trust boundaries exist and what validates transitions between zones.

Step 3: Inventory Critical Assets

Classify data by sensitivity:

1. PII (Personally Identifiable Information)

• User emails, names, addresses, phone numbers
• Document protection measures

2. Credentials & Secrets

• Password hashes, API keys, OAuth tokens
• JWT signing keys, encryption keys
• Document rotation policies

3. Business-Critical Data

• Transaction records, customer data
• Proprietary algorithms, trade secrets
• Document access controls

Step 4: Apply STRIDE Analysis

For each major component, analyze threats in all six categories:

S - Spoofing Identity

• Can attackers impersonate users or services?
• Are authentication mechanisms secure?
• Look for: weak session handling, API key exposure, missing MFA

T - Tampering with Data

• Can attackers modify data in transit or at rest?
• Look for: SQL injection, XSS, mass assignment, missing input validation

R - Repudiation

• Can users deny actions they performed?
• Look for: missing audit logs, insufficient logging, no immutable trails

I - Information Disclosure

• Can attackers access data they shouldn't?
• Look for: IDOR, verbose errors, hardcoded secrets, data leaks in logs

D - Denial of Service

• Can attackers disrupt service availability?
• Look for: missing rate limits, resource exhaustion, algorithmic complexity

E - Elevation of Privilege

• Can attackers gain unauthorized access levels?
• Look for: missing authorization checks, role manipulation, privilege escalation

For each identified threat:

• Describe the attack scenario
• List vulnerable components
• Show code patterns to look for
• Note existing mitigations
• Identify gaps
• Assign severity (CRITICAL/HIGH/MEDIUM/LOW) and likelihood

Step 5: Document Vulnerability Patterns

Create a library of code patterns specific to this codebase's tech stack:

# Example: SQL Injection patterns for Python
# VULNERABLE
sql = f"SELECT * FROM users WHERE id = {user_id}"

# SAFE
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

Include patterns for:

• SQL injection
• XSS (Cross-Site Scripting)
• Command injection
• Path traversal
• Authentication bypass
• IDOR (Insecure Direct Object Reference)

Step 6: Generate Output Files

Create two files:

1. .factory/threat-model.md

Use the template in stride-template.md to generate a comprehensive threat model with:

• System overview with architecture description
• Trust boundaries and security zones
• Attack surface inventory
• Critical assets classification
• STRIDE threat analysis for each component
• Vulnerability pattern library
• Security testing strategy
• Assumptions and accepted risks
• Version changelog

The document should be written in natural language with code examples, optimized for LLM comprehension.

2. .factory/security-config.json

Generate configuration metadata:

{
  "threat_model_version": "1.0.0",
  "last_updated": "<ISO timestamp>",
  "security_team_contacts": [],
  "compliance_requirements": [],
  "scan_frequency": "on_commit",
  "severity_thresholds": {
    "block_merge": ["CRITICAL"],
    "require_review": ["HIGH", "CRITICAL"],
    "notify_security_team": ["CRITICAL"]
  },
  "vulnerability_patterns": {
    "enabled": [
      "sql_injection",
      "xss",
      "command_injection",
      "path_traversal",
      "auth_bypass",
      "idor"
    ],
    "custom_patterns_path": null
  }
}

Customize based on:

• Detected compliance requirements (from docs, configs, or user input)
• Security team contacts (if provided)
• Tech stack (enable relevant vulnerability patterns)

Success Criteria

The skill is complete when:

• [ ] .factory/threat-model.md exists with all sections populated
• [ ] .factory/security-config.json exists with valid JSON
• [ ] All major components have STRIDE analysis
• [ ] Vulnerability patterns match the tech stack
• [ ] Document is written in natural language (LLM-readable)
• [ ] No placeholder text remains

Verification

Run these checks before completing:

# Verify threat model exists and is non-empty
test -s .factory/threat-model.md && echo "✓ Threat model exists"

# Verify config is valid JSON
cat .factory/security-config.json | jq . > /dev/null && echo "✓ Config is valid JSON"

# Check threat model has key sections
grep -q "## 1. System Overview" .factory/threat-model.md && echo "✓ Has System Overview"
grep -q "## 5. Threat Analysis" .factory/threat-model.md && echo "✓ Has Threat Analysis"
grep -q "## 6. Vulnerability Pattern Library" .factory/threat-model.md && echo "✓ Has Pattern Library"

Example Invocations

Generate initial threat model:

Generate a threat model for this repository using the threat-model-generation skill.

Update existing threat model after architecture change:

Update the threat model - we added a new payments service in services/payments/.

Generate with compliance requirements:

Generate a threat model for this repository. We need to comply with SOC2 and GDPR.

References

• STRIDE Threat Modeling
• OWASP Threat Modeling
• Template: stride-template.md (in this skill directory)

STRIDE Threat Model Template

This template defines the structure for .factory/threat-model.md. When generating a threat model, follow this structure and replace all {placeholder} values with actual content.

---

Output File: .factory/threat-model.md

# Threat Model for {Repository Name}

**Last Updated:** {YYYY-MM-DD}
**Version:** {X.Y.Z}
**Methodology:** STRIDE + Natural Language Analysis

---

## 1. System Overview

### Architecture Description

{Write a natural language description of the system, as if explaining to a security researcher. Include:}

This is a {type of application} that allows users to {primary functions}. The system is built using {technology stack} and consists of {number} main components:

1. **{Component Name}** - {Description of what it does and why it exists}
2. **{Component Name}** - {Description of what it does and why it exists}
3. **{Component Name}** - {Description of what it does and why it exists}

### Key Components

| Component   | Purpose   | Security Criticality | Attack Surface |
| ----------- | --------- | -------------------- | -------------- |
| {Component} | {Purpose} | {HIGH/MEDIUM/LOW}    | {Entry points} |
| {Component} | {Purpose} | {HIGH/MEDIUM/LOW}    | {Entry points} |

### Data Flow

{Describe how data moves through the system in natural language:}

When a user {action}, the system {process}. This involves {data flow description}. The data is validated at {points} and authenticated using {mechanism}.

---

## 2. Trust Boundaries & Security Zones

### Trust Boundary Definition

The system has **{N} trust zones**:

1. **Public Zone** - Untrusted external users and systems

   - Assumes: Malicious input, no authentication
   - Entry Points: {List all public entry points}

2. **Authenticated Zone** - Verified users with valid sessions

   - Assumes: User may be malicious but has valid credentials
   - Entry Points: {List protected endpoints}

3. **Internal Zone** - Service-to-service communication
   - Assumes: Services are trusted but data may be poisoned
   - Entry Points: {List internal APIs, databases}

### Authentication & Authorization

{Explain how auth works in natural language:}

Users authenticate using {method}. Sessions are managed via {mechanism} with {expiry}. Authorization is enforced using {RBAC/ABAC/custom} at {enforcement points}.

**Critical Security Controls:**

- {Control 1}
- {Control 2}
- {Control 3}

---

## 3. Attack Surface Inventory

### External Interfaces

#### Public HTTP Endpoints

{List all endpoints exposed to the internet:}

- `{METHOD} {/path}` - {Description}

  - **Input:** {Parameters and types}
  - **Validation:** {What validation is performed}
  - **Risk:** {Potential attack vectors}

- `{METHOD} {/path}` - {Description}
  - **Input:** {Parameters and types}
  - **Validation:** {What validation is performed}
  - **Risk:** {Potential attack vectors}

#### File Upload Endpoints

- `{METHOD} {/path}` - {Description}
  - **Input:** {File types, metadata}
  - **Validation:** {Type whitelist, size limits, malware scan}
  - **Risk:** {Malicious upload, path traversal, XXE}

### Data Input Vectors

The system accepts user input from:

1. {Input vector 1}
2. {Input vector 2}
3. {Input vector 3}

---

## 4. Critical Assets & Data Classification

### Data Classification

#### PII (Personally Identifiable Information)

- **{Data type}** - {How it's used}
- **{Data type}** - {How it's used}

**Protection Measures:** {Encryption, access controls, logging}

#### Credentials & Secrets

- **{Secret type}** - {How it's protected}
- **{Secret type}** - {How it's protected}

**Protection Measures:** {Secrets manager, rotation policy, never logged}

#### Business-Critical Data

- **{Data type}** - {Why it's critical}
- **{Data type}** - {Why it's critical}

---

## 5. Threat Analysis (STRIDE Framework)

### Understanding STRIDE for This System

We analyze threats using Microsoft's STRIDE methodology. Each category represents a different type of security threat.

---

### S - Spoofing Identity

**What is Spoofing?**
An attacker pretends to be someone or something they're not to gain unauthorized access.

#### Threat: {Threat Name}

**Scenario:** {Describe the attack scenario}

**Vulnerable Components:**

- {Component 1}
- {Component 2}

**Attack Vector:**

1. {Step 1} 2. {Step 2} 3. {Step 3} 4. {Outcome}

````

Code Pattern to Look For: ```{language} // VULNERABLE: {Why this is vulnerable} {vulnerable code example}

// SAFE: {Why this is safe} {safe code example} ````

Existing Mitigations:

• {Mitigation 1}
• {Mitigation 2}

Gaps:

• {Gap 1}
• {Gap 2}

Severity: {CRITICAL/HIGH/MEDIUM/LOW} | Likelihood: {VERY HIGH/HIGH/MEDIUM/LOW}

---

T - Tampering with Data

What is Tampering? Unauthorized modification of data in memory, storage, or transit.

Threat: {Threat Name}

{Follow same structure as Spoofing section}

---

R - Repudiation

What is Repudiation? Users can deny performing actions because there's insufficient audit logging.

Threat: {Threat Name}

{Follow same structure as Spoofing section}

---

I - Information Disclosure

What is Information Disclosure? Exposing information to users who shouldn't have access.

Threat: {Threat Name}

{Follow same structure as Spoofing section}

---

D - Denial of Service

What is Denial of Service? Attacks that prevent legitimate users from accessing the system.

Threat: {Threat Name}

{Follow same structure as Spoofing section}

---

E - Elevation of Privilege

What is Elevation of Privilege? Gaining higher privileges than intended.

Threat: {Threat Name}

{Follow same structure as Spoofing section}

---

6. Vulnerability Pattern Library

How to Use This Section

This section contains code patterns that indicate vulnerabilities. When analyzing code:

1. Look for these specific patterns 2. Consider the context (is input sanitized earlier?) 3. Check if mitigations are in place 4. Cross-reference with STRIDE threats above

---

SQL Injection Patterns

```{language}

PATTERN 1: String concatenation in SQL

{vulnerable pattern}

PATTERN 2: Dynamic query building

{vulnerable pattern}

SAFE ALTERNATIVE:

{safe pattern}

### XSS (Cross-Site Scripting) Patterns

// PATTERN 1: innerHTML with user data {vulnerable pattern}

// PATTERN 2: Unescaped template rendering {vulnerable pattern}

// SAFE ALTERNATIVE: {safe pattern}

### Command Injection Patterns

PATTERN 1: Shell command with user input

{vulnerable pattern}

PATTERN 2: Eval-style functions

{vulnerable pattern}

SAFE ALTERNATIVE:

{safe pattern}

### Path Traversal Patterns

PATTERN 1: User-controlled file paths

{vulnerable pattern}

SAFE ALTERNATIVE:

{safe pattern}

### Authentication Bypass Patterns

PATTERN 1: Missing authentication check

{vulnerable pattern}

PATTERN 2: Client-side role checking only

{vulnerable pattern}

SAFE ALTERNATIVE:

{safe pattern}

### IDOR Patterns

PATTERN: Direct object access without authorization

{vulnerable pattern}

SAFE ALTERNATIVE:

{safe pattern}

---

## 7. Security Testing Strategy

### Automated Testing

| Tool                 | Purpose                 | Frequency         |
| -------------------- | ----------------------- | ----------------- |
| {SAST tool}          | Static analysis         | Every commit      |
| {Dependency scanner} | Vulnerable dependencies | Daily             |
| {Secrets detection}  | Leaked credentials      | Every commit      |
| {DAST tool}          | Dynamic testing         | Weekly on staging |

### Manual Security Reviews

Human review is required for:

- HIGH/CRITICAL findings
- New authentication/authorization code
- Changes to cryptographic functions
- Admin privilege management changes

---

## 8. Assumptions & Accepted Risks

### Security Assumptions

1. **{Assumption}** - {Why we assume this is secure}
2. **{Assumption}** - {Why we assume this is secure}
3. **{Assumption}** - {Why we assume this is secure}

### Accepted Risks

1. **{Risk}** - {Why we're accepting it, mitigation timeline if any}
2. **{Risk}** - {Why we're accepting it, mitigation timeline if any}

---

## 9. Threat Model Changelog

### Version {X.Y.Z} ({YYYY-MM-DD})

- Initial threat model created
- STRIDE analysis completed for all components
- Vulnerability pattern library established

### Version {X.Y.Z} ({YYYY-MM-DD})

- {What changed}

---

Guidelines for Using This Template

Writing Style

1. Use natural language - Write as if explaining to a security researcher 2. Include code examples - Show vulnerable AND safe patterns 3. Be specific - Reference actual file paths, function names, endpoints 4. Attack scenarios as narratives - Step-by-step, numbered sequences

Severity Ratings

Likelihood Ratings

LLM Optimization Tips

For maximum effectiveness with downstream security skills:

1. Explicit code patterns - LLMs match patterns better than prose descriptions 2. Step-by-step attack vectors - Numbered steps help trace exploitability 3. Structured sections - Consistent headings enable targeted retrieval 4. Cross-references - Link threats to specific code locations when known