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
1---2name: threat-modeling3description: 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.4---56# Threat modeling78## Purpose910Identify threats at trust boundaries, propose mitigations, and rank residual risk so teams can decide what must ship-block vs follow-up vs accepted risk.1112## When to Use1314- User asks for threat model, STRIDE review, or security design review.15- New auth flows, APIs, admin tools, or third-party integrations.16- Pre-ship security sign-off on a feature or architecture change.1718## When NOT to Use1920- Vulnerability scanning only → **snyk**, **flag-security-issues**.21- Incident postmortem → **postmortem-authoring**.22- Penetration test execution without design context.2324## Expected Outcome2526- Ranked threat list with asset, threat, impact/likelihood, mitigation, residual risk, owner.27- Clear ship/no-ship recommendations for must-fix items.2829## Inputs to Gather3031- Architecture diagram or data-flow description.32- Trust boundaries (Internet, VPC, admin, third parties).33- Authn/z model, data classification, and compliance constraints.34- Existing controls (WAF, mTLS, rate limits).3536## Workflow37381. Scope the feature/system and draw trust boundaries.392. Apply STRIDE (or agreed framework) per component/data flow.403. For each threat: asset, threat, likelihood/impact, mitigation, residual risk.414. Rank: must-fix before ship, follow-up, accepted risk (with owner).425. Link mitigations to tickets/docs when tools available.4344## Domain guidance4546Use a structured lens (e.g. STRIDE) on **trust boundaries**: authn/z, data flows, third parties, admin paths.4748For each finding: asset, threat, likelihood/impact (qualitative is fine), **mitigation**, residual risk.4950Output a ranked list: must-fix before ship vs follow-up vs accepted risk (with owner).5152## Tool Availability Rules5354| Access | Behavior |55|--------|----------|56| Full tool access | File findings to **jira** / **google-docs** when asked. |57| Read-only | Produce threat model document only. |58| No integrations | Markdown output; user distributes. |5960### Related tool sets6162- `jira`63- `google-docs`6465## Review / Decision / Execution Criteria6667- Cover authz bypass, injection, secrets exposure, and supply chain where relevant.68- Mitigations concrete (not "use best practices" alone).69- Accepted risks have named owners and review date.7071## Output Format7273Table or bullets: ID, asset, threat, risk, mitigation, residual, priority, owner.7475## Quality Bar7677- Useful for security + engineering negotiation before ship.78- Grounded in described architecture, not generic OWASP laundry lists without mapping.7980## Safety and Boundaries8182- Do not include live secrets or exploitable PoC steps in customer-visible docs without need.83- Do not fabricate compensating controls that do not exist.8485## Escalation / Dispatch Rules8687- Dependency CVEs → **snyk**.88- Deep code review → **shadow-code-reviewer**, **flag-security-issues**.8990## References9192- `skills/old_skills.json` (`threat-modeling`).93- `skills/skill.instruction.md`, `skills/meta.instructions.md`
poly-gents