threat-modelinglisted

# Threat Modeling ## Purpose Security work without a threat model is a checklist applied uniformly: much effort spent on things nobody would attack, and the actual valuable target left open. A threat model asks four questions in order -- *what are we building, what can go wrong, what will we do about it, did we do a good enough job* -- and produces a **ranked** list, so that effort follows value. ## When to use - Designing any feature involving money, accounts, personal data, user-generated content, or competitive standing. - Scoping a security review, so the review has a target list rather than a mood. - Triaging a reported weakness: deciding whether it matters and how much. - Before launch, as a release gate for anything that handles value. - When adding a new external interface, integration, or dependency. ## When NOT to use - Implementing a specific defence you have already decided on. Use `secure-coding` or the platform's security skill. - Responding to an in-progress incident. Contain first; model afterwards. - Cryptographic design. Use vetted primitives and specialist review. - Trivial internal tooling with no valuable target -- say so explicitly and move on rather than performing the ceremony. ## Required context | Fact | Why it matters | |---|---| | What the system does, and its data flows | You cannot model what you cannot describe | | Trust boundaries | Where hostile input enters (see `client-server-trust`) | | What is valuable, to whom | Ranks everyt