From Alert Fatigue to Fleet-Driven Signal: Validating What's Actually Reachable

The supply side of findings is structural and accelerating. Roughly 41% of codebases are now AI-generated, and industry research puts the rate at which AI coding tasks introduce critical flaws or security issues near 45%. That is not a tooling anomaly you can wait out. It is the new baseline rate of risk creation, and your detection tools are doing their job by surfacing it.

The trouble is that detection tools are optimized to find candidates, not to prove exploitability. A scanner that flags a vulnerable dependency does not know whether the vulnerable function is ever called, whether the call path is reachable from an untrusted input, or whether a compensating control already neutralizes it. So it flags everything and defers the hard question to a human. Multiply that across every repo and every scan, and you get a queue that grows on the supply side while your drain rate stays bounded by analyst hours.

The second-order effect is worse than the backlog. When guardrails generate more noise than developers can absorb, they get bypassed. An estimated 80% of developers route around policy and guardrails when those guardrails are advisory or noisy. A finding queue that cries wolf trains your best engineers to ignore it. The cost of poor software quality, estimated at $2.41 trillion, is in large part the bill for risk that was visible in a queue nobody trusted enough to act on.

The only durable way to cut a finding queue is to change what you measure. Severity scores rank findings by how bad they would be in the abstract. Reachability ranks them by whether they can be triggered in your actual system. Those are different questions, and only the second one predicts incidents.

A finding is reachable when three conditions hold together:

Most findings fail at least one of these tests. A critical CVE in a transitive dependency whose vulnerable function is never invoked is, in your system, not exploitable. Ranking it above a medium-severity issue sitting on your authentication path is exactly the inversion that produces alert fatigue. Reachability fixes the inversion. Industry data on reachability-based prioritization points to 70-90% less exploitable exposure to act on, because you are triaging the small set that can actually be reached rather than the flat list of everything that was detected.

The catch is that reachability is not a static property you can compute once. It depends on the current shape of the system: which services call which, what is deployed where, what changed in the last release. A reachability verdict from last quarter is a guess today. This is why prioritization that relies on a one-time scan or a hand-drawn architecture diagram decays so fast. You need the determination to be change-aware, recomputed against the system as it actually is.

Determining reachability at scale is genuinely hard work. It requires mapping the live dependency graph, tracing whether a path is exercised, attempting to exercise it safely, observing the result, and re-checking the verdict whenever the system moves. No single static script does this, because static scripts encode yesterday's assumptions and rot the moment the system evolves. The thing that exercised the suspect path last sprint silently passes a refactored, still-vulnerable path this sprint, and nobody notices.

This is the work that Testing Fleets are built for: coordinated agents that plan, execute, observe, and maintain validation as systems change, rather than a fixed suite that ages out. Applied to a finding queue, a fleet does not just confirm that a flaw exists. It validates whether the flaw is reachable and exploitable in the current system, and it keeps that determination current as code and topology shift.

The fleet's coordination is grounded in a change-aware map. The System Graph is the live dependency and context map of services, dependencies, and CI/CD that tells the fleet which paths a given finding actually sits on and what a recent change touched. Without that map, agents are guessing at reachability; with it, they can focus validation on the paths that moved and the inputs that matter. Coordination is what turns raw agent capacity into signal: agents share the same model of the system, divide the validation work along real dependency edges, and converge on a verdict instead of producing ten redundant opinions.

The output is not another severity score. It is an evidence-backed verdict: this finding is reachable from this entry point, exercised by this path, not mitigated by an existing control, here is the reproduction. That verdict is what a human can act on without re-deriving the analysis from scratch.

Reframing the queue around fleet-validated reachability changes the work in specific, measurable ways.

Crucially, none of this removes the human from the decision. The governing principle is that agents propose and humans authorize. The fleet validates and proposes a prioritized, evidence-backed picture of exploitable risk. The security lead decides what gets remediated, in what order, and under what policy. For regulated environments, the same work can run inside your boundary on Edge Runners, signed capsules that execute in secure enclaves and produce audit-ready evidence without code or data leaving your control. The longer argument for this shift lives in the alert fatigue to engineering velocity whitepaper, and Governance is where the policy and audit model is defined.

You do not need to replace your scanners to test this. They are fine at detection. The leverage is in adding a reachability layer between detection and human triage.