threat-modellisted

# Threat Model The cheapest security fix is the one made before the code exists. This skill runs a disciplined pass over a design to surface risks early, using STRIDE so the analysis is systematic rather than "whatever we happen to think of." The core question repeated at every trust boundary: **what does an attacker gain by spoofing, tampering, denying, disclosing, disrupting, or escalating here?** ## When to reach for this skill Use it at design time: a new system or service, a new feature touching data or auth, an architecture diagram, a set of API contracts, or any "how should we build X?" where X handles sensitive data, money, identity, or multi-tenant access. If the user is still deciding *how* to build something, this is the moment — cheaper than auditing it later. ## The method ### 1. Establish scope and assets Name what you're protecting before hunting threats. Identify: the sensitive assets (user data, credentials, money, tenant boundaries, PII), the actors (anonymous users, authenticated users, admins, external services), and the trust boundaries (where data crosses from less-trusted to more-trusted — client→server, service→service, user→tenant). Threats live at trust boundaries; that's where to look hardest. ### 2. Apply STRIDE at each boundary For each trust boundary and data flow, walk the six STRIDE categories and ask whether each applies: - **Spoofing** — can an attacker pretend to be someone else? (weak auth, stealable tokens, no service-to-servic