Security Design Review
A structured examination of an architecture's security properties before it is built, focused on trust boundaries and threat paths rather than on a checklist.
The economics are the argument for doing it early: a trust boundary drawn in the wrong place is a design decision, and changing it after implementation means changing the system. A missing header is a bug. Reviews that happen before build catch the first kind; reviews that happen before launch catch only the second.
What a good review examines, in order. Trust boundaries — where does data cross from a less-trusted context to a more-trusted one, and what validates it there. Identity and authorisation — how is the caller identified at each hop, and is authorisation enforced at the resource rather than only at the gateway. Data — what sensitive data exists, where does it go, where is it at rest, who can read it. Blast radius — if this component is fully compromised, what does the attacker reach, and what stops lateral movement. Secrets and credentials — where they live, how they rotate, what has standing access.
The failure to avoid is the review as a gate staffed by people seeing the system for the first time an hour before sign-off. That produces generic findings and resentment. Reviews work when they are collaborative and early, when the reviewer engages with the actual threat model rather than a standard list, and when findings carry a severity that distinguishes a design flaw from a hardening suggestion.