Produces a STRIDE-based security threat model. Identifies assets, trust boundaries and threats, and assigns a mitigation and verification method to each. Operates the SEC-THREAT gate.
Installs into .claude/skills of the current project.
Are you the author of Threat Model?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/bturksoy-threat-model)
---
name: threat-model
description: Produces a STRIDE-based security threat model. Identifies assets, trust boundaries and threats, and assigns a mitigation and verification method to each. Operates the SEC-THREAT gate.
---
# /threat-model
Owner: `security-engineer`. Output: `docs/security/threat-model.md`
Prerequisite: `ARCHITECTURE.md` (plus `openapi.yaml` if available).
Mandatory in `full` mode; optional in `lean`; skipped in `solo`.
---
## 1. Input
- Architecture: containers, trust boundaries, external systems
- API: endpoint list + auth schemes (not the full YAML)
- Data: which entities are sensitive (personal, financial, health, credentials)
- Compliance requirements (GDPR/PCI etc. — from `NFR.md`)
- User roles and the permission matrix
## 2. Invoke `security-engineer`
```
<CONTEXT BLOCK>
Task: produce a STRIDE threat model.
1. Asset inventory
| Asset | Sensitivity | Where stored | Who accesses | Legal status |
2. Trust boundaries (Mermaid) — every boundary crossing is a control point
3. Threat table — apply all 6 STRIDE categories to each trust boundary:
Spoofing, Tampering, Repudiation, Information disclosure,
Denial of service, Elevation of privilege
| # | Boundary | STRIDE | Threat scenario | Impact | Likelihood | Risk | Mitigation | Verification |
The threat scenario must be CONCRETE: "if the attacker does X they obtain Y"
4. For every HIGH/CRITICAL risk:
- The required mitigation (actionable, at code/config level)
- The verification method (a test id or a check step)
- Which REQ/ADR it will be bound to
5. Risks recommended for acceptance (mitigation cost > risk) — with rationale
6. Security requirement proposals: items that should be added to NFR.md
Rules:
- Do NOT produce attack tooling or exploit code — describe the scenario
- If you cannot write an exploit scenario, it is not a finding but a theoretical concern
- Match the scale of this project; do not write an APT model for a 10-user internal tool
Begin your reply with "SEC-THREAT: APPROVED|CONDITIONAL|REJECTED".
```
## 3. Present
```
## Threat Model
Assets: <N> | Trust boundaries: <M> | Threats: <K>
Risk distribution: Critical <a> | High <b> | Medium <c> | Low <d>
Required mitigations (Critical/High):
| # | Threat | Mitigation | Where it will be bound |
Risks recommended for acceptance: <list>
NFR proposals: <list>
Gate: SEC-THREAT <verdict>
```
Have the user confirm the risks to accept via `AskUserQuestion` — this is a
**business decision**, not one the security engineer can make alone.
## 4. Write
- `docs/security/threat-model.md`
- Propose the required mitigations **as NFRs** to `business-analyst` (list them in the
report — you do not modify `NFR.md`)
- Add accepted risks to `product/risks.md` (with owner + review date)
- `.state/gates.jsonl`
## 5. Close
```
✓ Threat model → docs/security/threat-model.md
<K> threats | <a> critical/high mitigations required
⚠ These mitigations must become stories: <list>
Include them when you run /epics.
▶ Next: /epics
```
---
## Token note
- **1 agent call.**
- Depth should match project scale — do not produce 60 threats for a small project; 15 is enough.
- Do not embed the whole API; the endpoint list plus auth schemes is enough.
