Awesome-omni-skill threat-model-generation
Generate a STRIDE-based security threat model for a repository. Use when setting up security monitoring, after architecture changes, or for security audits.
git clone https://github.com/diegosouzapw/awesome-omni-skill
T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/testing-security/threat-model-generation" ~/.claude/skills/diegosouzapw-awesome-omni-skill-threat-model-generation && rm -rf "$T"
skills/testing-security/threat-model-generation/SKILL.mdThreat Model Generation
Generate a comprehensive security threat model for a repository using the STRIDE methodology.
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
| Input | Description | Required |
|---|---|---|
| Repository path | Root directory to analyze | Yes (default: current directory) |
| Existing threat model | Path to existing if updating | No |
| Compliance requirements | Frameworks to consider (SOC2, GDPR, HIPAA, etc.) | No |
Instructions
Step 1: Analyze Repository Structure
Scan the codebase to understand the system:
-
Identify languages and frameworks
- Check
,package.json
,requirements.txt
,go.mod
, etc.Cargo.toml - Note the primary tech stack
- Check
-
Map components and services
- Look for
,apps/
,services/
directoriespackages/ - Identify entry points: API routes, CLI commands, web handlers
- Note databases, caches, message queues
- Look for
-
Identify external interfaces
- HTTP endpoints (REST, GraphQL)
- File upload handlers
- Webhook receivers
- OAuth/SSO integrations
-
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
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
-
Business-Critical Data
- Transaction records, customer data
- Proprietary algorithms, trade secrets
Step 4: Apply STRIDE Analysis
For each major component, analyze threats:
S - Spoofing Identity
- Can attackers impersonate users or services?
- Are authentication mechanisms secure?
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
I - Information Disclosure
- Can attackers access data they shouldn't?
- Look for: IDOR, verbose errors, hardcoded secrets
D - Denial of Service
- Can attackers disrupt service availability?
- Look for: missing rate limits, resource exhaustion
E - Elevation of Privilege
- Can attackers gain unauthorized access levels?
- Look for: missing authorization checks, role manipulation
Step 5: Document Vulnerability Patterns
Create a library of code patterns specific to this codebase's tech stack.
Step 6: Generate Output Files
Create two files:
1. .factory/threat-model.md
.factory/threat-model.mdComprehensive 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
2. .factory/security-config.json
.factory/security-config.json{ "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" ] } }
Success Criteria
-
exists with all sections populated.factory/threat-model.md -
exists with valid JSON.factory/security-config.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
Example Invocations
Generate initial threat model:
Generate a threat model for this repository.
Update existing threat model:
Update the threat model - we added a new payments service.
Generate with compliance requirements:
Generate a threat model for this repository. We need to comply with SOC2 and GDPR.