A security design review consistently produces findings that are expensive to act on. What is wrong with the process?
Show the full answer Hide the answer
What is wrong
It happens too late. A review conducted after the design is fixed can only produce a list of mitigations, because the decisions that would have addressed the findings have already been made and built on.
A security design review is a design activity; performed after implementation it is a vulnerability assessment — useful, and a different thing.
What makes it effective
- Conducted during design, when the answer can be "then we will not do it that way" rather than "we will add a mitigation".
- Scoped to one flow or boundary, since a model of one flow that changes the design is worth more than a model of the system that changes nothing.
- Starting from what the adversary wants, concretely — obtain another tenant's data, escalate to administrative access, exfiltrate credentials — rather than from a catalogue of techniques.
- Producing specific testable mitigations with owners and dates, and being willing to record "accepted" with a named accepter, since an accepted risk with an owner is a legitimate outcome and a long unprioritised list is not.
- Triggered by a stated rule — a new trust boundary, a change to authentication, a new data classification, an external integration — so the review is a routine part of the process rather than an act of dissent.
The measure of success
Did the design change? If no decision was altered, the review documented the system rather than improving it — and that question at the end is more useful than the finding count.
The finding that only design review produces
Structural decisions: that untrusted file processing belongs in an isolated environment with no ambient credentials and no egress; that tenant isolation must be enforced in the engine rather than in application code; that the model must be treated as an untrusted component proposing actions.
No scanner produces these, and no vulnerability assessment does — they come from asking what an adversary would do while the architecture is still changeable.