mn-youssef/security-skills/threat-modeling

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

1. Inventory assets — What's valuable? (user data, money, credentials, PII, admin control, IP)
2. 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.

1. 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.

1. Apply STRIDE per boundary/component — see references/stride-and-surface.md.
2. Rank — score each threat: risk = likelihood × impact (1–3 each → 1–9).

Test high scores first.

Quick reference — STRIDE

Output: prioritized target list

A table the next phases consume:

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.