Threat Model Generator

Generate STRIDE-based threat models for new features or services based on architecture descriptions.

Integrations: GitHub MCP, Jira MCP

When to Use

• The user is designing a new feature, microservice, or system and needs a security review
• A security audit or compliance requirement mandates threat modeling for architecture changes
• The user mentions "threat model", "STRIDE", "security review", or "architecture risk assessment"
• Before a design review or security sign-off for a new component

Steps

Step 1: Gather Architecture Information

Collect or infer from the user:

Input Source	What to Extract
Architecture diagram	Components, data flows, trust boundaries
Design document	External dependencies, authentication flows, data handling
Code repository	API endpoints, data stores, third-party integrations
User description	Sensitive data types (PII, secrets, payment data), user roles

Document: component inventory, data flow diagram (DFD) elements, and trust boundary locations.

Step 2: Identify Trust Boundaries

Map boundaries where trust levels change:

Boundary Type	Example	Threats to Consider
External ↔ Internal	Internet → API Gateway	Spoofing, DoS
Service ↔ Service	Lambda → DynamoDB	Tampering, Info Disclosure
User ↔ System	Mobile app → Backend	Repudiation, Elevation
Cross-tenant	Multi-tenant SaaS	Info Disclosure, Elevation

Create a simple DFD showing components and trust boundaries. Use GitHub MCP to store the diagram or document if requested.

Step 3: Apply STRIDE Analysis

For each component and data flow, evaluate STRIDE categories:

STRIDE Category	Question to Ask	Example Threats
Spoofing	Can an actor pretend to be someone/something else?	Fake API client, credential theft
Tampering	Can data be modified in transit or at rest?	Request injection, DB tampering
Repudiation	Can actions be denied without evidence?	Missing audit logs, unsigned requests
Information Disclosure	Can sensitive data be exposed?	Logs, error messages, public buckets
Denial of Service	Can the system be made unavailable?	Rate exhaustion, cold-start abuse
Elevation of Privilege	Can a principal gain higher privileges?	Over-permissive IAM, injection

Populate a threat matrix: one row per threat, columns for category, affected component, description, and initial risk.

Step 4: Score and Prioritize Threats

Apply risk scoring (e.g., likelihood × impact) and prioritize:

Risk Level	Criteria	Action
Critical	High impact + high likelihood	Immediate mitigation, Jira P1
High	High impact or high likelihood	Mitigation within sprint, Jira P2
Medium	Moderate impact and likelihood	Plan for roadmap, Jira P3
Low	Low impact and likelihood	Accept or defer with rationale

Produce a ranked list of threats with recommended mitigations for each.

Step 5: Generate Mitigation Plan

For each high/critical threat, define:

Element	Description
Mitigation	Specific control or design change
Owner	Team or role responsible
Effort	S/M/L or story points
Dependencies	Prerequisites or other mitigations

Use Jira MCP to create Epics and Stories for tracking. Optionally store the full threat model in GitHub as a markdown document.

Output

Deliver:

• STRIDE threat matrix (table: Category, Threat, Risk, Mitigation)
• Data flow diagram or component diagram indicating trust boundaries
• Prioritized list of top 5–10 threats with mitigations
• Jira Epic "Threat Model — [Feature Name]" with Stories for each mitigation (if Jira MCP available)
• Optional: Markdown document in GitHub for versioned threat model documentation