Every sprint, your SAST tool hands your team another queue of findings. Four thousand. Maybe five thousand. Most engineers I talk to have stopped looking at the count — they just know it's a number too large to act on. We built Runtimekindle specifically because we watched this happen at scale, and the math behind alert fatigue is worse than most security leads realize.
Where the 78% Number Comes From
The figure that shaped our product: in a study of cloud-native applications across containerized workloads, approximately 78% of SAST findings point to code paths that are never reached during runtime. That is not a rounding error. It means that if your scanner surfaces 4,000 findings in a sprint, roughly 3,120 of them describe vulnerabilities in dead code — functions that are imported but never called, classes instantiated only in test fixtures, library code included by a transitive dependency but never invoked from your actual request paths.
Static analysis tools cannot distinguish between reachable and unreachable code. They operate on the source tree alone, without knowledge of which functions are on live execution paths. That is not a flaw — it is a design constraint. SAST was built to be fast and exhaustive, not to model runtime behavior. The gap between what a scanner sees and what an attacker can actually reach is where most remediation effort disappears.
We've seen this in practice. One fintech series-B engineering team we work with was spending an average of 22 developer-hours per sprint on SAST triage before integrating runtime reachability context. After filtering on reachability, the same sprint produced 340 actionable findings instead of 3,900. Same codebase. Same scanner. Different signal quality.
How Static Analysis Ends Up Generating So Much Noise
To understand why noise is so persistent, consider what happens when a modern cloud-native service pulls in its dependencies. A typical Node.js microservice might have 300–600 transitive npm packages. A Python service using a standard ML framework stack can pull in 800+ transitive packages. Each package carries its own dependency tree, and each file in that tree gets scanned.
Here's the structural problem: most of those packages are used for a small fraction of their exposed API surface. Your application calls three functions from a library that exports sixty. The scanner finds a vulnerability in one of the fifty-seven functions you never call. The CVE is real. The risk to your running application is zero. But the finding still lands in your queue at "Critical" severity because the CVSSv3 base score is 9.8.
Multiply that across 300 packages, add in first-party code with similar coverage gaps, and you get a queue that no team can realistically triage. The result is one of two failure modes: teams start ignoring high-severity findings because most are false positives, or teams block releases on phantom risks because their security gate cannot distinguish signal from noise.
"The goal of application security should be accurate risk signal, not maximal alert volume. If your security tooling generates more noise than signal, you haven't made your application more secure — you've trained your engineering team to deprioritize security work."
— Yael Cohen, CEO & Co-Founder, Runtimekindle
What Runtime Reachability Analysis Actually Does
Runtime reachability analysis starts from a different data source than static analysis. Instead of scanning the source tree, it instruments the running application container — typically via eBPF or bytecode instrumentation depending on the language runtime — to build a live call-graph of actual execution paths.
The call-graph captures which functions are actually invoked during execution: under real traffic, during integration test runs, and during canary deployments. That graph becomes the filter layer on top of your SAST results. Every finding gets scored against the call-graph: is the vulnerable function reachable from any live call path? If not, the finding is suppressed or down-ranked. If yes, it surfaces at elevated priority.
The key insight is that this is not a replacement for static analysis — it is a post-processing layer that makes static analysis results actionable. You still want the scanner's exhaustive coverage of every potential vulnerability. You just want the output ranked by real-world exposability, not theoretical severity alone.
At Runtimekindle, our instrumentation agent adds an average overhead of under 2% to application CPU and memory, measured across our benchmark suite of 12 language runtimes. The call-graph is built continuously and updated as traffic patterns evolve — so a function that is unreachable today but called after a new feature ships gets promoted automatically without requiring a manual re-scan.
The Remediation Math Changes Completely
Here is what actually changes for engineering teams when they filter on reachability. The 4,000-finding queue does not disappear — it reorganizes. Roughly 78% moves to a "suppressed" state with documented reason (no live call path). The remaining 22% — approximately 880 findings — surfaces as requiring active review. Of those, perhaps 40% are genuinely critical after combining reachability with exploitability scoring against the CISA KEV catalog and CVSS environmental scores.
That gives you a workable number. 350 findings per sprint is still a lot, but it is a number a security team can triage in a few days rather than a number that defeats any attempt at systematic remediation.
More importantly, the findings you do act on are the right ones. Mean-time-to-remediate matters less when your engineers are fixing vulnerabilities that can actually be reached by an attacker. We've tracked remediation rates across our customer base: teams that filter on reachability close high-severity findings 4x faster on average than teams triaging unfiltered SAST output. The difference is not engineering capacity — it is motivation and clarity. Engineers move fast when they understand the finding is on a live request path, not buried in an uncalled library function.
Integrating Reachability Context Into Your Pipeline
The operational model for runtime reachability does require one architectural commitment: you need to be willing to instrument your application containers. For most cloud-native teams already running Kubernetes, this means deploying a sidecar or DaemonSet agent — a step that typically takes under an hour with existing CI/CD tooling.
The workflow then becomes:
- SAST scanner runs on each commit as normal, producing the full findings list.
- Reachability agent in staging or production environment pushes updated call-graph data to the platform.
- Each finding is scored: reachability score (1–10) combined with CVSS environmental score produces a prioritized queue.
- Pipeline security gate uses reachability score as the blocking threshold, not raw CVE count.
- Engineers see only runtime-reachable findings in their Jira/GitHub Issues/Slack alert feed.
The staging environment is sufficient for reachability signal in most cases. Production instrumentation adds higher-fidelity data (real traffic vs. synthetic tests), but staging call-graphs typically cover 85–90% of live code paths for services with reasonable integration test coverage. Teams that start with staging instrumentation and later add production get an incremental accuracy improvement without needing to wait for production rollout to begin reducing noise.
What This Means for Security Teams and Developers
The organizational benefit of reachability filtering is often underestimated. When security teams stop filing tickets for unreachable vulnerabilities, two things happen. First, developer trust in security findings goes up — engineers learn that a security ticket means a real risk, not another phantom alert. Second, security leads can hold the line on SLA compliance for genuine findings because they are no longer drowning in noise that makes SLA tracking meaningless.
We've measured the downstream effect of this trust shift: teams with reachability-filtered security queues patch critical findings 60% faster than teams without reachability context, even holding engineering capacity constant. The signal quality improvement alone drives faster action.
Application security has been stuck in an alert-volume arms race for years. More scanners, more findings, more dashboards — and slower remediation, more alert fatigue, more gate bypasses. The path forward is not more alerts. It's better signal. Runtime reachability is the most direct route from static analysis output to actionable risk information — and for cloud-native teams running instrumented containers, it is available right now with no significant overhead.
If your team is triaging a four-figure SAST queue each sprint and closing fewer than 20% of findings, the problem is almost certainly not effort. It's signal quality. That is the problem Runtimekindle was built to solve.
