About threat-modeling
A threat-modeling skill for the security planning phase, helping teams map assets, entry points, and trust boundaries before testing. It applies STRIDE and ranks risks by likelihood and impact to produce a prioritized list for audits and penetration tests.
Key features
- 01Inventory assets and input points
- 02Map trust boundaries
- 03Analyze threats with STRIDE
- 04Score risk by likelihood and impact
- 05Produce a prioritized test-target list
Use cases
- 01Prioritize security testing efforts
- 02Review threats across APIs and internal entry points
- 03Prepare targets for code audits
- 04Identify attack surfaces without specialist coverage
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/threat-modelingin Claude Code to confirm it loaded.
Bundled filesreferences/stride-and-surface.md
Details
From the project READMEThreat Modeling (PLAN phase)
Overview
Decide what to worry about and test first before spending effort. Map assets, entry points, and trust boundaries; apply STRIDE; rank risks by likelihood × impact.
Core principle: You can't test everything. Spend effort where a break hurts most.
Process
- Inventory assets — What's valuable? (user data, money, credentials, PII, admin control, IP)
- Map entry points — Every place untrusted input enters: routes/endpoints, forms, file uploads, query params, headers, webhooks, message queues, mobile API calls, third-party callbacks.
- Draw trust boundaries — Where does data cross from less-trusted to more-trusted? (browser→API, API→DB, service→service, user→admin). Bugs cluster on these lines.
- Apply STRIDE per boundary/component — see
references/stride-and-surface.md. - Rank — score each threat:
risk = likelihood × impact(1–3 each → 1–9). Test high scores first.
Quick reference — STRIDE
| Threat | Question | Defends |
|---|---|---|
| Spoofing | Can someone pretend to be another user/service? | Authentication |
| Tampering | Can data be modified in transit/at rest? | Integrity |
| Repudiation | Can an action be denied / is it logged? | Non-repudiation |
| Information disclosure | Can data leak? | Confidentiality |
| Denial of service | Can it be made unavailable? | Availability |
| Elevation of privilege | Can a user gain rights they shouldn't? | Authorization |
Output: prioritized target list
A table the next phases consume:
| # | Asset | Entry point | STRIDE | Likelihood | Impact | Risk | Test via |
|---|---|---|---|---|---|---|---|
| 1 | User PII | GET /api/users/:id | I (IDOR) | 3 | 3 | 9 | code-audit + active-pentest |
| 2 | Auth | POST /login | S | 2 | 3 | 6 | code-audit |
Hand-off
Feed the top items into security-code-audit (find) and active-pentest (validate).
The surface inventory is also the applicability driver. It tells the security-testing
orchestrator which specialists apply (surface present → run) and which to skip (absent → N/A),
and exposes any surface with no matching specialist as a coverage gap to handle with the
generic methodology + a recommendation to build a new skill. List every surface you found —
including ones no current skill covers — so nothing is silently missed.
Common mistakes
- Modeling the happy path only — attackers use the unhappy paths.
- Forgetting internal/trusted entry points (admin panels, internal APIs, cron, queues).
- Treating all findings as equal — rank, or you'll drown in low-value work.