threat-modelinglisted

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/threat-modeling/SKILL.md. --> # Threat Modeling Review a design or architecture for security flaws — trust boundaries, authorization, data flow, and attack surface — before code is written ## ALWAYS - Start a new feature/service by naming the **assets** (data, funds, credentials, keys, compute) and the **actors** (users, tenants, services, admins, attackers). You cannot secure what you have not named. - Draw the **trust boundaries** — every point where data crosses from a less-trusted zone to a more-trusted one (internet→app, tenant→shared store, service→service, user-input→interpreter). Each crossing needs authentication, authorization, and input validation *at the crossing*. - Treat **authorization as a design decision**: for every resource decide who may read/write it and enforce it at the **object level** (owner/tenant scoping), not just "is authenticated". Design tenant isolation as a boundary the data model enforces, not a WHERE-clause a developer must remember every time. - Map the **data flow of every sensitive datum** (credentials, PII, tokens, keys, financial): where it enters, is stored, transits, and leaves, and who can read it at each hop. Apply least-privilege and encryption at rest / in transit by design. - Enumerate the **attack surface each change adds** — a new endpoint, input, dependenc