Security Without the Review Queue

In many organizations a finished change waits days in a review queue before it can ship. The queue exists because security review is treated as a uniform manual gate: every change, regardless of risk, lines up behind a human before it reaches production. The fix is not to skip security but to stop treating review as a per-change gate; convert it into automated, risk-based guardrails so the common case never waits on a person. The queue then disappears without weakening security, and the gate stays only where the risk earns it.

The argument has four moves: automate the common case, route only genuinely high-risk changes to a human, make the secure path the default path, and put dependency hygiene on a cadence. Each one reinforces the same point: security review should not own your lead time. For the broader cadence picture this sits inside, see Compressing Time to Production; for the axis where rollback itself is the constraint, see the client you cannot roll back.

The Review Queue as a Lead-Time Tax

Lead time for changes is the clock from commit to running in production. Any minute a change sits idle in a queue is pure wait-state, and a mandatory manual security review is one of the most reliable sources of it. The gate is serial and applied uniformly: a one-line copy change and a new authentication flow join the same line, so the average change inherits the wait time of the riskiest change.

DORA’s guidance on pervasive security is the permission slip for treating this as a number to drive down, not a fixed cost of doing business. It frames the review explicitly in lead-time terms: measure “how much time the review adds to the development process,” and that time “should go down until it reaches an agreed-to minimum,” while “the security review process doesn’t slow down development.” The agreed-to minimum is the goal; a static multi-day queue is the failure mode.

The deeper reason this is allowed is that speed and stability are not a tradeoff. DORA’s research has held since 2015 that high performers achieve both, and the Accelerate book makes the same case from the data. So a security gate that adds days is not buying safety in exchange for speed; it is adding wait-state that the evidence says you do not have to accept. (The full DORA framing, and how the performance bands shift per yearly survey, is covered in the cadence overview linked above rather than re-derived here.)

The clock above runs end to end, but the review queue is the segment that grows without bound when it depends on human availability. The other segments are bounded by machine time; the queue is bounded by a backlog. That asymmetry is why it dominates lead time, and it is the segment worth compressing.

Build Quality In, Not Inspect

The first move is to stop inspecting changes after they are “done” and instead build the checks into the pipeline. DORA states it in Deming’s terms: “cease dependence on inspection to achieve quality” and “build quality into the product” by automating security controls into the delivery pipeline. Concretely, that means static analysis (SAST), dependency and composition analysis (SCA), secret scanning, and dynamic analysis (DAST) run on every change as pipeline steps, not as a separate phase a person schedules later.

When controls run in the pipeline, two things change. The common case is verified by machines in the time it takes the build to run, so a clean change does not wait on a human at all. And audit evidence is produced as a byproduct; DORA’s framing is that you “generate evidence on demand” for auditors instead of assembling it manually under deadline. The review queue shrinks because most changes no longer enter it.

OWASP’s DevSecOps Maturity Model gives a concrete adoption ladder for this. At Level 2, SAST, SCA, and DAST run in CI with automated reporting. At Level 3, “pipelines are configured to fail based on severity thresholds,” with enforced remediation timelines so findings do not pile up in a separate queue. The progression matters: scanning that only reports is advisory, while scanning that fails the build on a threshold is an actual gate that does not need a person to hold it.

A caveat keeps this honest. DORA reported in 2016 that teams integrating security into delivery spent about half as much remediation time, but that figure is dated and correlational, and its source sentence covers security alongside performance and availability rather than security alone. Treat it as directional support, not a causal promise. Automation triages the common case and surfaces findings early; it does not replace human judgment for the changes where judgment is the point. That is what the next move addresses.

Risk-Based Review, Not a Uniform Gate

Automation thins the queue, but the lever that removes it is routing. The principle is to classify every change by risk and send only genuinely high-risk changes to a human; everything else clears through automated gates or a self-service path. The uniform gate fails precisely because it refuses to make this distinction, taxing the copy change at the rate of the auth change.

NIST’s Secure Software Development Framework is built on exactly this premise. The SSDF is “outcome-based,” and its authors are explicit that “the intention of the SSDF is not to create a checklist to follow, but instead to provide a basis for planning and implementing a risk-based approach.” It also names automation as a first-class concern: “automatability is an important factor to consider, especially for implementing practices at scale.” A risk-based, automatable framework is the formal warrant for routing instead of gating.

The routing diagram below is the spine of this whole approach. A risk classifier sits in front of three lanes. Low-risk changes clear on automated gates alone. Medium-risk changes take a paved-road self-service path with built-in controls. Only high-risk changes (new authentication, changes to data handling, new external surface, sensitive permissions) get white-glove human review. Border color reads as risk level: green clears automatically, amber is self-service, red is the human lane.

The trade-off worth stating plainly is that routing concentrates human attention where it pays off rather than spreading it thin across every change. The risk classifier becomes a thing you own and tune; misclassification is the new failure mode, so the criteria for the high-risk lane need to be explicit and reviewable. But this is a far better problem than a uniform queue. It does not claim automation removes the need for review; it claims review should be reserved for the changes that actually need it, and that the reservation should be made by policy, not by a backlog.

The Paved Road

Routing tells you which lane a change takes; the paved road is what makes the common lanes safe by default. The idea is to make the secure path the path of least resistance: a central platform where the defaults (authentication, secrets handling, network policy, base images, logging) are already correct, so a team picks up security by using the platform rather than by passing a review.

Netflix described this directly in its account of scaling application security. The strategy was “secure by default central platforms,” and the conclusion is the one worth internalizing: “driving adoption of these security controls reduces more application risk… than vulnerability remediation does.” The reasoning is structural. “Per-app security assessments… do not scale,” so chasing individual findings one app at a time loses against a platform that fixes a class of risk everywhere at once. This is one company’s experience rather than a universal mandate, but the scaling argument generalizes: a control adopted by default outperforms a finding fixed by hand.

The paved road and the routing model fit together. A guardrail is a control built into the path; a gate is a checkpoint a person staffs. The table below contrasts them on the dimensions a lead actually cares about.

Dimension	Manual gate	Paved-road guardrail
Who acts	A reviewer, per change	The platform, automatically
When it acts	After the change is “done”	While the change is built
Blast radius of a fix	One change at a time	Every change using the platform
Lead-time impact	Adds wait-state per change	None in the common case
Scales with	Reviewer headcount	Platform adoption

Netflix also kept a human lane: “white glove” review for high-risk teams and changes. That is the same high-risk lane from the routing diagram, and it is the honest boundary. The paved road removes the queue for the common case; it does not abolish human review for the cases where the stakes justify it.

Shipping Vulnerability-Free Code on a Cadence

“How often should we ship secure code?” is usually answered with a periodic dependency audit, which handles risk in bursts and lets vulnerable transitive dependencies linger between audits. The better answer is a cadence: automate dependency updates so patching is continuous, and adopt supply-chain provenance incrementally so each level of assurance is a step you can take rather than a project you defer.

Automated dependency updates, through tools like Dependabot or Renovate, turn patching from a periodic event into a steady stream of small pull requests. GitHub’s Octoverse 2025 reports concrete movement here: critical fixes landed about 30% faster, with median time-to-remediation dropping from 37 days to 26 days, and 26% fewer repositories carried critical alerts. Adoption tracked the cadence, with Dependabot enabled on more than 2.66 million repositories, up about 24% year over year. These are reported population figures, not a controlled experiment, but they describe the shape a cadence produces: faster fixes, fewer lingering criticals.

Note: A widely repeated “about 40% fewer vulnerabilities” figure circulates for automated dependency updates. It is unsourced and is not used here; the Octoverse 2025 numbers above are the verifiable ones.

Supply-chain provenance is the other half, and its value is that it is incrementally adoptable. The SLSA build track (cite v1.2) defines a ladder rather than a single bar. Build Level 1 means provenance exists: the build emits a record of how the artifact was produced. Level 2 adds signed provenance from a hosted build platform, which defends against tampering with the artifact after the build. Level 3 requires a hardened build platform, defending against tampering during the build itself. You can start at L1 for visibility and climb as the assurance becomes worth the cost.

A software bill of materials (SBOM) belongs in this picture as the inventory that makes the rest tractable: it lists what is in a build so that, when a new vulnerability lands, you can answer “are we affected?” without a manual sweep. It is the catalog, not the remediation; pairing it with automated updates is what turns a known exposure into a routine pull request rather than a fire drill.

The Honest Counterweight

The recommendation is to automate the common case, route by risk, and put dependencies on a cadence, so security stops owning your lead time. The boundary on that recommendation is the part most worth taking seriously: guardrails compress lead time only when the paved road is genuinely self-service. A half-built platform does the opposite of what it promises.

DORA’s 2024 research is the counterweight here. It found that adopting an internal developer platform improved developer productivity, but was associated directionally with a short-term decline in throughput (on the order of 8%) and stability (on the order of 14%); the exact figures vary across secondary summaries, so treat them as a single secondary signal rather than a precise measurement. DORA’s stated cause was added handoffs, not the security steps themselves. The security gloss is a plausible mechanism, not DORA’s finding: a security platform that is not actually self-service inserts a new handoff between a team and production, which is just the old review queue wearing a platform’s clothes.

That gives a clean test. A guardrail that a team cannot satisfy without filing a ticket and waiting is not a guardrail; it is a gate with extra steps. The whole value of the model depends on the common path being walkable without a human in the loop, so the platform has to be finished enough that the default path is the easy path. If it is not, you have added a queue, not removed one.

The single next step is the cheapest and the most clarifying: measure the wait time your security review adds to lead time today. Once that number exists, every move above becomes a lever against it. Automate the common case first, route the remainder by risk, and the queue stops being the line item that owns when you ship.

References

• DORA — Capabilities: Pervasive security - Frames review time as a lead-time metric to minimize and makes the build-quality-in argument.
• Scaling Appsec at Netflix - Guardrails over gates; per-app assessments do not scale; white-glove review for high-risk teams.
• NIST SSDF (SP 800-218) - Outcome-based and risk-based rather than a checklist; the PO/PS/PW/RV practice groups.
• OWASP DevSecOps Maturity Model - Level 2 automated scanning in CI; Level 3 severity-threshold pipeline failures.
• SLSA v1.2 — Build track basics - Incrementally adoptable supply-chain assurance levels (L1 to L3).
• GitHub Octoverse 2025 - Dependency-remediation figures: 30% faster critical fixes, 37 to 26 days, 26% fewer repos with critical alerts.
• DORA — A history of DORA’s metrics - The since-2015 no-tradeoff finding and how performance bands change yearly.
• DORA 2024 State of DevOps Report - The platform-engineering throughput and stability counterweight.
• Are you an Elite DevOps performer? — Google Cloud - Lead time for changes defined as commit to production.
• Accelerate (Forsgren, Humble, Kim) - The data behind “speed and stability are not a tradeoff.”