security-reviewlisted

Threat modeling is hypothesis generation for an adversary. Walk the change set as the attacker would: where does untrusted input enter, what trust boundary does it cross, what does it gain on the other side. Every unaudited path is a free move for the attacker. ## When to Apply / NOT Apply: new external surface (HTTP route, RPC method, file upload); AuthN/AuthZ change; deserialization / parsing of untrusted input; new dependency or major-version upgrade; cryptographic change; pre-release of public-facing service; incident postmortem. NOT apply: internal refactor with no trust-boundary delta; pure performance work; documentation-only changes; internal-only experimental code. ## Anti-patterns - **Allowlist-by-omission**: treating "no obvious issue" as "secure". - **Crypto improvisation**: hand-rolling primitives. - **Trust the client**: validating only client-side. - **Logging secrets**: tokens, PII, session cookies in logs. - **Default-permit ACL**: authorization checks on opt-in basis. - **Magic-string config**: secrets in source / env files. - **Outdated SBOM**: stale dependency snapshots. - **Skipping the threat model**: jumping to checklist without naming assets/actors/boundaries. ## STRIDE Question Template Apply each prompt to every component touched by the change. | Letter | Threat | Required questions | |---|---|---| | **S** | Spoofing | Who is the principal? How is identity proven? Can the credential be forged, replayed, or stolen? Is MFA / mutual-auth enforce