Field Note: Paved Roads, Not Gatekeeping: Security Engineering That Scales

A central security team that reviews every change will lose to the rate of change. It then does one of two things: it becomes a queue that delivery teams route around, or it signs off on reviews it has not had time to do. Both outcomes look like governance. Neither gives assurance.

This field note sets out the alternative that security engineering teams use: build the secure way as the easy way, then spend scarce review effort only where the paved road does not reach. It is a Cybrilliant practitioner view built on public evidence. It describes patterns, not named client engagements.

The scale problem, in public numbers

Verizon’s 2026 Data Breach Investigations Report executive summary gives two figures that frame the problem. Vulnerability exploitation was the most common initial access vector at 31% of breaches. And only 26% of critical vulnerabilities on the CISA Known Exploited Vulnerabilities catalog were fully remediated in 2025, down from 38% the year before, with a median of 43 days to full resolution. The dataset is global and weighted to the US, so read it as a pattern and not as a UAE rate.

The Equifax record shows what manual hand-offs look like at scale. The patch instruction went by email to about 430 people and mailing lists. The House Oversight report records that the patch was not applied within the 48 hours the policy required, and that both scanning tools failed to find the vulnerable component. A broadcast is not a control.

What a paved road is

A paved road is a supported, pre-secured way to do a common job: deploy a service, store data, call an API, build an image. Teams that use it inherit the controls. Teams that leave it take on the burden of showing equivalent assurance.

NIST SP 800-160 Volume 1 Revision 1 supplies the vocabulary. Protective defaults: the default configuration of the system gives maximum protection effectiveness. Reduced complexity: the design is as simple as practicable. Commensurate rigor: the rigor of an engineering activity should match the most significant adverse effect that can occur. Together they say what a paved road is for: secure by default, simple enough to trust, with review effort scaled to impact.

Building the road: five decisions

1. Pick the top three jobs by volume. Do not pave everything. Choose the three activities your delivery teams repeat most (for example: deploy a container workload, provision a storage bucket, expose an API). A road nobody needs stays empty.

2. Make the secure option the default. A road that needs a security flag to be safe has not applied the protective-defaults principle. Defaults should not depend on a person remembering to switch something on.

3. Put the check in the path. Pipeline checks, policy-as-code and template validation catch departures when the change is made, not at a quarterly review. Our reading: a check that runs after release is monitoring, not engineering.

4. Design the exit. Teams will have valid reasons to leave the road. Give them a documented route: what evidence they owe, who approves, and when the exception lapses.

5. Measure adoption and drift. Count the share of workloads on the road and the exceptions past their expiry. NIST SP 800-55 Volume 1 distinguishes implementation measures (progress against a control) from effectiveness measures (does the control work). Adoption is an implementation measure. Pair it with a test of effect.

Where this fails

• The road is slower than the shortcut. If a team can ship faster off the road, the road loses. Treat road performance as a product metric.

• The road is not maintained. A road that falls behind current threats creates false assurance for everyone on it. Assign an owner and a release cadence.

• Security is not staffed to build. Paving needs engineers who can write code and templates. A review-only team cannot do it.

• Regulated scope is treated as optional. Where a regulator requires specific evidence or prior approval, the road must produce that evidence. It does not replace it.

Decision

Decision: choose the one activity that produces the most security tickets, and pave it first. Measure ticket volume and time-to-ship before and after. If neither moves, the road is wrong.

What this evidence does not show

No public source here measures the effect of paved roads on breach rates. Verizon’s figures describe exploitation and remediation, not engineering models. The Equifax report describes one company. The NIST principles describe design intent, not proven outcomes.

A short test

List the last ten changes your security team reviewed. For each, ask: could a template or pipeline check have made this review unnecessary? If the answer is yes for more than half, you are spending review capacity on work that a road could do.

Sources

1. NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems, November 2022. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf

2. NIST SP 800-55 Vol. 1, Measurement Guide for Information Security, December 2024. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-55v1.pdf

3. Verizon, 2026 Data Breach Investigations Report, Executive Summary. Accessed 9 October 2026. verizon.com/business/resources/executivebriefs/2026-dbir-executive-summary.pdf

4. US House Committee on Oversight and Government Reform, Majority Staff Report, The Equifax Data Breach, December 2018. Accessed 9 October 2026. oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf