Use this when you need to systematically identify threats to a system -- when designing a new architecture, onboarding onto a client's system, preparing for a security review, or responding to a risk assessment request. Goes beyond feature-level security review to model threats across an entire system.

Related skills: Use /system-diagram for architecture input. Use /security-review for per-feature deep dives on high-risk components. Use /adr-generate for security architecture decisions. Use /architecture-discovery for domain boundary analysis.

Process

Step 1: Gather system context

Ask the user for:

• Architecture diagram or description (or run /system-diagram to generate one)
• Data flows -- what data moves where, in what format, over what protocols
• Trust boundaries -- where do privilege levels change?
• Authentication and authorization mechanisms
• External integrations (third-party APIs, SaaS dependencies, payment processors)
• Data sensitivity classification (PII, PHI, financial, public, internal)

If the user provides a description rather than a diagram, sketch a component list with data flows before proceeding.

Step 2: Identify trust boundaries

Map every point where data crosses a trust boundary:

• Client to server -- browser/mobile app to backend API
• Service to service -- internal microservice communication
• Internal to external -- calls to third-party APIs, webhooks
• User to admin -- privilege escalation boundaries
• Encrypted to unencrypted -- TLS termination points, decryption for processing
• Network zones -- public internet, DMZ, private subnet, database tier

Document each boundary with: source, destination, protocol, authentication method, data sensitivity.

Step 3: Apply STRIDE per component

For each component that sits on or crosses a trust boundary, analyze six threat categories:

Be specific about attack vectors. Not "the API could be attacked" but "an unauthenticated user could enumerate valid user IDs via timing differences in the login response."

Step 4: Generate the threat matrix

Produce a table covering every identified threat:

| Threat ID | STRIDE Category | Affected Component | Threat Description | Likelihood (1-5) | Impact (1-5) | Risk Score (L x I) | Existing Controls | Residual Risk |
|---|---|---|---|---|---|---|---|---|
| T-001 | {{category}} | {{component}} | {{specific_attack_vector}} | {{1-5}} | {{1-5}} | {{score}} | {{current_controls}} | {{low/medium/high/critical}} |

Scoring guidance:

• Likelihood: 1 = requires nation-state capability, 5 = script kiddie with public tools
• Impact: 1 = minor inconvenience, 5 = regulatory action, mass data breach, business shutdown
• Risk score: multiply likelihood by impact. Critical >= 20, High >= 12, Medium >= 6, Low < 6

Step 5: Produce prioritized mitigations

For each threat rated high or critical, recommend a mitigation:

| Threat ID | Recommended Control | Control Type | Implementation Effort | Priority |
|---|---|---|---|---|
| T-001 | {{specific_control}} | Preventive / Detective / Corrective | S / M / L | {{P1-P4}} |

Every mitigation must be actionable -- include enough detail that an engineer could estimate and plan the work. "Implement rate limiting" is too vague. "Add per-IP rate limiting at the API gateway (100 req/min for unauthenticated, 1000 req/min for authenticated) with 429 responses and alerting at 80% threshold" is actionable.

Step 6: Annotate the data flow diagram

Mark the system diagram (or component list) with:

• Trust boundary lines (dashed borders around zones)
• Threat entry points (numbered, referencing threat IDs)
• Highest-risk components (highlighted)
• Data sensitivity labels at each flow

If starting from a text description, produce a labeled component diagram in Mermaid or ASCII.

Step 7: Review

Ask the user:

• Are there components or integrations we missed?
• Does the team have threat intelligence -- known attack patterns against similar systems?
• Are there compliance requirements that mandate specific controls (PCI-DSS, HIPAA, SOC 2)?
• What's the team's current security posture -- mature security practice or greenfield?
• Which threats feel most realistic given the organization's exposure?

Output location

Deliver the threat model as a markdown document. Suggested filename: threat-model-{{system-name}}-{{date}}.md. Store in the project's security documentation directory or deliver directly to the requesting team.