mcpbeat

Threat Model Generation

factory-ai/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.

5k tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
101
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/Factory-AI/factory-plugins --skill threat-model-generation

What comes with it

9 972 bytes besides the instruction
stride-template.md

The instruction itself

22 sections, as written by the author

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

How to use it

Copy the folder

Take factory-ai/threat-model-generation from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.