Security Design Review
Reviewing an architecture for security while changing it is still cheap.
5 to work through
-
intermediate
A security design review consistently produces findings that are expensive to act on. What is wrong with the process?
2 min answer -
intermediate
Security reviews happen the week before launch. Findings are usually rejected as too late to fix. How do you change this?
2 min answer -
intermediate
Your security design review template asks for data flows, trust boundaries, authentication and encryption. A team submits a support assistant that reads customer ticket text and calls three internal APIs with a service account, one of which issues refunds. The template produces no findings. What would you add to it, and what would you leave alone?
3 min answer -
advanced
A developer-tools company of JetBrains' shape has six security engineers for 200 developers shipping desktop IDEs, a plugin marketplace and a hosted build service. It replaces mandatory pre-launch security review with a self-service threat-modelling questionnaire plus a trigger list, keeping deep review for triggered changes. What has it given up, and when does that bill arrive?
3 min answer -
advanced
A security team of six supports two hundred engineers. Design reviews are a bottleneck. What do you do?
1 min answer
3 terms in this topic
Design Review Trigger
The stated conditions under which a change requires security review, so that review capacity goes to what warrants it and everything else proceeds.
practiceLaunch-Blocking Finding
The rule that a design review holds a launch only for findings whose remediation cost explodes once real users exist, and turns everything else into …
practiceSecurity 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 c…
Neighbouring topics
Assurance, Audit & Model Risk
General material on assurance, architectural governance and risk oversight.
Control Design vs Operation
A control that is well designed and never runs fails exactly like one that is absent.
Audit Evidence
Producing durable, tamper-evident proof as a by-product rather than as a project.
Certification Impact on Architecture
What SOC 2 and ISO 27001 actually require of a design, and what they do not.
Continuous Controls Monitoring
Testing controls continuously instead of sampling them once a year.
Segregation of Duties
Splitting authority so no single actor can both make and approve a change.
Change Advisory vs Automated Gates
Replacing a weekly board with evidence a machine produces on every change.
Risk Appetite
The stated tolerance that tells you which risks you are allowed to accept.
Risk Assessment Methods
Qualitative matrices, FAIR and scenario analysis, and the illusion of a precise score.
Architecture Compliance Checks
Automating conformance to standards so review effort goes to the genuinely novel.
Exception & Waiver Management
Time-boxed, owned deviations with a remediation date, rather than permanent silence.
Design Authority
How an ARB should decide, what it should not review, and how it avoids becoming a queue.
Three Lines Model
Ownership, oversight and independent assurance, and where architecture sits in it.
Model Risk Management
Inventory, validation, monitoring and challenge for models that make consequential decisions.
AI Risk Tiering
Classifying a use case by potential harm, and the obligations each tier triggers.
Model Documentation
Model cards, intended use, limitations, and the record a regulator will ask for.
Model Evaluation & Red-Teaming
Adversarial testing of a probabilistic system with no fixed expected output.
Bias & Fairness Controls
Measuring disparate outcomes, choosing a fairness definition, and living with the trade-off.
Human-in-the-Loop Design
Meaningful review rather than a rubber stamp, and designing against automation bias.