Speckit Threat Model

Threat Model Generation

Generate a structured threat model from a feature specification using STRIDE methodology.

Prerequisites

Before starting, locate:

1. The feature spec (.speckit/features/<feature>/spec.md or provided by user)
2. The project constitution (.speckit/constitution.md) for security constraints
3. The project stack (check package.json, CLAUDE.md)

Process

Step 1: Identify Assets and Trust Boundaries

Read the spec and identify:

• Data assets: What data does this feature handle? (PII, credentials, financial, content)
• Entry points: API routes, form inputs, webhooks, file uploads
• Trust boundaries: Client/server, authenticated/anonymous, admin/user, internal/external services
• Dependencies: Third-party services, databases, auth providers

Step 2: STRIDE Analysis

For each entry point, evaluate all 6 STRIDE categories:

Step 3: Risk Assessment

For each identified threat, assess:

• Likelihood: Low / Medium / High
• Impact: Low / Medium / High / Critical
• Risk Level: Likelihood x Impact matrix
• Existing mitigations: What the current stack already handles (e.g., Supabase RLS, Next.js CSRF)

Step 4: Mitigation Recommendations

For each Medium+ risk threat, propose:

• Specific code-level mitigation (Zod validation, RLS policy, rate limiting, etc.)
• Which story/task should implement it
• Whether it blocks the feature or can be addressed post-MVP

Step 5: Generate Report

Output to docs/security/<feature>-threat-model.md:

# Threat Model: <Feature Name>

**Date**: YYYY-MM-DD
**Spec**: .speckit/features/<feature>/spec.md
**Author**: Claude (automated)

## 1. Overview

Brief description of the feature and its security context.

## 2. Assets

| Asset | Type | Sensitivity |
|-------|------|------------|
| ... | PII / Financial / Content / System | High / Medium / Low |

## 3. Trust Boundaries

Diagram (text-based):

[Browser] --HTTPS--> [Next.js API] --SQL--> [Database] | | Trust Boundary 1 Trust Boundary 2

## 4. Threats (STRIDE)

### T-001: <Threat Name>
- **Category**: Spoofing / Tampering / ...
- **Entry Point**: POST /api/xxx
- **Description**: ...
- **Likelihood**: Medium
- **Impact**: High
- **Risk**: HIGH
- **Existing Mitigation**: Supabase RLS on table X
- **Recommended Mitigation**: Add Zod validation on input field Y
- **Priority**: Must-fix before MVP / Post-MVP acceptable

### T-002: ...

## 5. Risk Matrix

|          | Low Impact | Medium Impact | High Impact | Critical Impact |
|----------|-----------|--------------|-------------|----------------|
| **High** | Medium    | High         | Critical    | Critical       |
| **Medium** | Low     | Medium       | High        | Critical       |
| **Low**  | Info      | Low          | Medium      | High           |

## 6. Summary

- Total threats identified: N
- Critical: N | High: N | Medium: N | Low: N
- Must-fix before MVP: N
- Status: PASS / WARN / FAIL

Status Levels

• PASS: No Critical or High threats without mitigation
• WARN: High threats exist but have proposed mitigations
• FAIL: Critical threats without clear mitigation path

Common Patterns by Stack

Supabase + Stripe

• Check RLS policies cover all tables touched by the feature
• Verify webhook signature validation for Stripe events
• Ensure service_role key is never exposed client-side
• Check that Supabase auth tokens are validated server-side

Next.js (both starters)

• Server Actions: validate all inputs with Zod
• API routes: check authentication before processing
• Middleware: verify redirect targets are same-origin
• Environment variables: ensure no NEXT_PUBLIC_ prefix on secrets