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:

Input Description Required

Repository path Root directory to analyze Yes (default: current directory)

Existing threat model Path to existing .factory/threat-model.md if updating No

Compliance requirements Frameworks to consider (SOC2, GDPR, HIPAA, etc.) No

Security contacts Email addresses for security team notifications No

Instructions

Follow these steps in order:

Step 1: Analyze Repository Structure

Scan the codebase to understand the system:

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)

Map components and services

• Look for apps/ , services/ , packages/ directories

• Identify entry points: API routes, CLI commands, web handlers

• Note databases, caches, message queues

Identify external interfaces

• HTTP endpoints (REST, GraphQL)

• File upload handlers

• Webhook receivers

• OAuth/SSO integrations

• CLI commands that accept user input

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:

Public Zone (untrusted)

• All external HTTP endpoints

• Public APIs without authentication

• User-uploaded files

Authenticated Zone (partially trusted)

• Endpoints requiring valid session/token

• User-specific data access

• Rate-limited APIs

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:

PII (Personally Identifiable Information)

• User emails, names, addresses, phone numbers

• Document protection measures

Credentials & Secrets

• Password hashes, API keys, OAuth tokens

• JWT signing keys, encryption keys

• Document rotation policies

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)