| name | threat-modeling |
| description | Performs STRIDE-style threat modeling on features and systems with ranked mitigations and residual risk. Use before shipping new surfaces, auth flows, or third-party integrations. |
Threat modeling
Purpose
Identify threats at trust boundaries, propose mitigations, and rank residual risk so teams can decide what must ship-block vs follow-up vs accepted risk.
When to Use
- User asks for threat model, STRIDE review, or security design review.
- New auth flows, APIs, admin tools, or third-party integrations.
- Pre-ship security sign-off on a feature or architecture change.
When NOT to Use
- Vulnerability scanning only → snyk, flag-security-issues.
- Incident postmortem → postmortem-authoring.
- Penetration test execution without design context.
Expected Outcome
- Ranked threat list with asset, threat, impact/likelihood, mitigation, residual risk, owner.
- Clear ship/no-ship recommendations for must-fix items.
Inputs to Gather
- Architecture diagram or data-flow description.
- Trust boundaries (Internet, VPC, admin, third parties).
- Authn/z model, data classification, and compliance constraints.
- Existing controls (WAF, mTLS, rate limits).
Workflow
- Scope the feature/system and draw trust boundaries.
- Apply STRIDE (or agreed framework) per component/data flow.
- For each threat: asset, threat, likelihood/impact, mitigation, residual risk.
- Rank: must-fix before ship, follow-up, accepted risk (with owner).
- Link mitigations to tickets/docs when tools available.
Domain guidance
Use a structured lens (e.g. STRIDE) on trust boundaries: authn/z, data flows, third parties, admin paths.
For each finding: asset, threat, likelihood/impact (qualitative is fine), mitigation, residual risk.
Output a ranked list: must-fix before ship vs follow-up vs accepted risk (with owner).
Tool Availability Rules
| Access | Behavior |
|---|
| Full tool access | File findings to jira / google-docs when asked. |
| Read-only | Produce threat model document only. |
| No integrations | Markdown output; user distributes. |
Related tool sets
Review / Decision / Execution Criteria
- Cover authz bypass, injection, secrets exposure, and supply chain where relevant.
- Mitigations concrete (not "use best practices" alone).
- Accepted risks have named owners and review date.
Output Format
Table or bullets: ID, asset, threat, risk, mitigation, residual, priority, owner.
Quality Bar
- Useful for security + engineering negotiation before ship.
- Grounded in described architecture, not generic OWASP laundry lists without mapping.
Safety and Boundaries
- Do not include live secrets or exploitable PoC steps in customer-visible docs without need.
- Do not fabricate compensating controls that do not exist.
Escalation / Dispatch Rules
- Dependency CVEs → snyk.
- Deep code review → shadow-code-reviewer, flag-security-issues.
References
skills/old_skills.json (threat-modeling).skills/skill.instruction.md, skills/meta.instructions.md
