From Alert Fatigue to Engineering Velocity: Scoring Exposure by Reachability

This is not the security debt you inherited five years ago. The composition of the codebase has changed underneath the tooling that scans it.

Industry research now puts roughly 41% of codebases as AI-generated, and estimates that around 45% of AI coding tasks introduce critical flaws or security issues. That combination is not a marginal increase in finding volume. It is a step change. A scanner tuned for human-paced commits, applied to machine-paced generation with a near coin-flip defect rate, produces a backlog that grows faster than any human team can triage it. The cost of poor software quality, estimated at $2.41 trillion, is in large part the bill for findings that were seen but never resolved because no one could tell the exploitable few from the irrelevant many.

The honest response to a flood is not a bigger bucket. It is a filter that is defensible. Reachability is that filter, and unlike severity-only triage, it is grounded in the actual structure of the running system rather than a property of the vulnerability in the abstract.

Reachability asks a specific, falsifiable question about each finding: given the system as it is deployed, can untrusted input or an attacker-controlled path actually arrive at this vulnerable code, under conditions that let it execute?

A vulnerable function in a dependency you import but never call is not reachable. A critical CVE in a code path gated behind authentication that the threat model excludes is reachable, but with different weight. A SQL injection on an endpoint exposed to the public internet, fed by user input, with no compensating control in between, is reachable and exploitable, and it should jump the entire queue.

Severity scoring treats all three as comparable because it grades the wrong thing. It grades the weapon, not whether the weapon is loaded and pointed at anything. Reachability re-grades the same findings against four questions:

When you score against those, the published outcome holds: reachability-based prioritization can mean 70-90% less exploitable exposure to act on. That is not noise you suppressed and hoped about. It is noise you can prove is not reachable, which is a categorically different and safer thing.

The reason reachability is talked about more than it is practiced is that doing it correctly requires something most security tooling does not have: a live, change-aware model of the system. You cannot determine reachability from a file. You determine it from the relationship between that file, the services that call it, the data flows that feed it, the deployment topology, and what changed in the last release.

A static list of findings has no idea what calls what. It cannot tell you that the vulnerable parser is only invoked behind a feature flag that is off in production, or that yesterday's dependency bump just made a previously dead path live. That context lives in the dependency and CI/CD graph, not in the scanner output.

This is precisely the job of a System Graph: a live dependency and context map of services, dependencies, and CI/CD that lets every finding be scored against current reality instead of a stale architecture diagram. Reachability computed against a graph is auditable. Reachability asserted by a scanner that cannot see the system is a guess wearing a confidence score.

There is a second trap worth naming. Reachability is not a one-time classification. A finding that is unreachable today becomes reachable the moment a route is added, a flag flips, or a service starts calling a library it never used. Static reachability analysis rots exactly like static test suites rot. It has to be recomputed as the system moves, which is why this belongs in continuous validation, not a quarterly scan.

Filtering the backlog is the entry-level benefit. The strategic value shows up when reachability becomes the axis your Reliability Analytics is organized around, because it changes which metrics you are allowed to trust.

Three shifts matter for a security lead:

From count to reachable trend. "Open findings" is a vanity number that goes up forever in an AI-generation regime. "Reachable, exploitable exposure over time" is a number you can actually drive toward zero and defend to a board. Track the second; report the second.

From coverage to validated reachable surface. Coverage percentages tell you what your tests touched. They do not tell you whether your tests touched the paths that are reachable and risky. Testing Fleets that plan and execute validation against the reachable surface, rather than running a fixed suite, produce a confidence signal tied to real exposure instead of a number tied to line counts.

From alert rate to escaped-reachable-defect rate. The metric that should keep you up at night is not how many alerts fired. It is how many reachable, exploitable issues escaped to production. That is the one that maps to incidents, and reachability scoring is what makes it measurable rather than anecdotal.

Cutting 70-90% of noise raises an obvious question: what happens to the reachable issues that remain? This is where prioritization meets governance, and where the temptation to over-automate has to be resisted.

A reachable, exploitable finding is a strong candidate for a proposed fix. But "proposed" is the operative word. The principle is agents propose, humans authorize. Remediation Fleets can generate a scoped fix for a reachable injection on a public endpoint, and that is genuinely useful leverage. Whether it executes, and on what path, is a policy decision routed through Governance with approval and an audit trail. Unsupervised autonomous fixing on a security-critical path is not velocity, it is a new incident class. The engineering is in the governance, not in removing the human from the one decision that warrants them.

This also addresses the failure mode behind most security debt: roughly 80% of developers bypass policy and guardrails when those guardrails are advisory and feel like noise. A guardrail that fires on every theoretical finding trains people to ignore it. A guardrail that fires only on reachable, exploitable exposure earns the right to be blocking, because when it speaks, it is almost always right. Reachability is how you make a gate credible enough that engineers stop routing around it.

You can test this without replacing your scanners.

The deeper argument lives in the From Alert Fatigue to Engineering Velocity whitepaper, and how the loop works shows where reachability sits in continuous validation.