Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Threat 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.