security-threat-model
# Security Threat Model Skill This Claude Code skill produces a structured STRIDE-based threat model for services or features, analyzing assets, trust boundaries, threat enumeration by component, risk scoring, and mitigation controls. Use it when asked to document security risks, identify attack vectors, assess a service's security posture, or prepare for a security design review. The output enables engineering teams to make informed, documented security decisions with specific enough detail that new engineers understand what is protected, why each control exists, and what risks have been accepted.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/security-threat-model && cp -r /tmp/security-threat-model/plugins/pm-engineering/skills/security-threat-model ~/.claude/skills/security-threat-modelSKILL.md
# Security Threat Model Skill
Produce a complete STRIDE-based threat model for a service or feature. A threat model is not a list of things that could go wrong — it is a structured analysis of attackers, assets, boundaries, and controls that lets an engineering team make informed, documented security decisions.
A good threat model is specific enough that a new engineer can understand what is being protected, why each control exists, and what risk the team has accepted.
## Required Inputs
Ask for these if not already provided:
- **Service name and description** — what the service does, who uses it
- **Architecture overview** — components, dependencies, data flows (a diagram description or ASCII diagram is fine)
- **Deployment environment** — cloud provider, VPC/network topology, where it runs (Kubernetes, ECS, VMs, serverless)
- **Data sensitivity** — what data does this service handle? PII, payment data, credentials, internal-only?
- **Existing controls** — authentication method, encryption in transit/at rest, current WAF/firewall, existing security scanning
- **Trust levels** — who are the principals? (anonymous public, authenticated users, internal services, admins)
## Output Format
---
# Security Threat Model: [Service Name]
**Service:** [Name] | **Team:** [Team name]
**Author:** [Name] | **Reviewed by:** [Security lead / peer]
**Date:** [Date] | **Next review:** [Date — recommend 6 months or after major architecture change]
**Classification:** [Internal / Confidential]
---
## 1. Overview
[2–3 sentences describing the service, its role in the system, and the scope of this threat model. State what is in scope and what is explicitly out of scope.]
**In scope:**
- [Component or data flow]
- [Component or data flow]
**Out of scope:**
- [e.g. Third-party payment processor internals]
- [e.g. Corporate network / end-user devices]
---
## 2. Asset Register
Assets are the things worth protecting — data, capabilities, and reputational value.
| Asset | Description | Sensitivity | Owner |
|---|---|---|---|
| [e.g. User PII] | Names, email addresses, profile data | High — GDPR-regulated | [Team] |
| [e.g. API credentials] | Service-to-service auth tokens | Critical | [Team] |
| [e.g. Session tokens] | User authentication state | High | [Team] |
| [e.g. Audit logs] | Record of user and admin actions | Medium | [Team] |
| [e.g. Service availability] | Uptime of the [X] endpoint | Medium | [Team] |
**Data classification key:**
- **Critical** — Credential material; exposure enables direct system compromise
- **High** — PII, financial data, health data; regulated or high reputational impact
- **Medium** — Internal configuration, non-sensitive business data
- **Low** — Public information, anonymised data
---
## 3. Trust Boundaries and Architecture
Trust boundaries are the lines that separate zones with different trust levels. Threats often occur when data or requests cross a boundary.
```
┌─────────────────────────────────────────────────────────────────┐
│ INTERNET (Untrusted) │
│ │
│ [Public User] [Bot / Attacker] │
└──────────────────────────────┬──────────────────────────────────┘
│ HTTPS
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
Trust Boundary: Public → DMZ
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
▼
┌──────────────────────────────────────────────────────────────────┐
│ DMZ / Edge Layer │
│ ┌────────────┐ ┌──────────────┐ │
│ │ WAF / CDN │────▶│ API Gateway │ │
│ └────────────┘ └──────┬───────┘ │
└──────────────────────────────┼───────────────────────────────────┘
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
Trust Boundary: Edge → Application VPC
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
▼
┌──────────────────────────────────────────────────────────────────┐
│ Application VPC (Private) │
│ ┌──────────────┐ ┌────────────┐ ┌──────────────────┐ │
│ │ [Service A] │────▶│ [Service B]│────▶│ [Database] │ │
│ └──────────────┘ └────────────┘ └──────────────────┘ │
│ ▲ │
│ │ │
│ ┌──────────────┐ │ │
│ │ Admin (IAM) │─────────────┘ │
└──────────────────────────────────────────────────────────────────┘
```
**Trust Boundaries identified:**
| Boundary | From | To | Auth mechanism | Encrypted |
|---|---|---|---|---|
| TB-1 | Public internet | API Gateway | [JWT / OAuth / API key] | TLS 1.2+ |
| TB-2 | API Gateway | Service A | [mTLS / internal JWT / IAM role] | [Yes/No] |
| TB-3 | Service A | Database | [Connection string + IAM / username+password] | [Yes/No] |
| TB-4 | Admin | Service B | [IAM role / VPN + MFA] | TLS |
---
## 4. STRIDE Threat Analysis
STRIDE is a threat classification framework. For each significant component, enumerate threats in each category.
**STRIDE key:**
- **S** — Spoofing: Impersonating another user, service, or system
- **T** — Tampering: Modifying data or code without authorisation
- **R** — Repudiation: Denying an action occurred; insufficient audit trail
- **I** — Information Disclosure: Exposing data to unauthorised parties
- **D** — Denial of Service: Making the service unavailable
- **E** — Elevation of Privilege: Gaining capabilities beyond what is authorised
### Component: [API Gateway / Auth Layer]
| ID | Category | Threat | Attack vector | Existing control |
|---|---|---|---|---|
| T-001 |Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.