How to Use Reachability to Cut Vulnerability Alerts

What Reachability Analysis Means in Application Security

Reachability analysis is a technique in application security that checks whether a vulnerable piece of code can actually run in your app. It reduces application security alerts by keeping only the flaws your code can actually reach. Also called vulnerability reachability, it filters findings down to the ones that deserve a human's attention.

For engineering teams, that means fewer alerts, fewer interruptions, and faster fixes. This guide answers one question: how does application security vulnerability reachability reduce alerts?

The core question it answers is simple: "Does this alert deserve a human?" If your code can never reach the vulnerable function, the alert can wait. If a path exists, that finding moves to the top of the list.

This reframing changes how you triage. Instead of sorting a giant list by severity, you start from a much smaller list of findings your code can actually reach. That is the heart of the alert-reduction thesis.

Two terms make this work. A call graph is a map of which functions call which other functions across your application. An entry point is any place where outside input enters your app, such as an API route or a request handler.

Reachability follows the call graph from each entry point to see if a path leads to the vulnerable code. Endor Labs walks through reachability analysis in more depth if you want the full method.

Present vs. Reachable vs. Exploitable

These three words describe a ladder of certainty. Present means a scanner found a vulnerable dependency in your project.

Reachable means a path exists from an entry point to the vulnerable function. Exploitable means the flaw is reachable and has real-world exploit activity behind it.

Here is a quick example. A library you import has a CVE in one function, but your code never calls that function.

The package is present, yet the vulnerable code is unreachable, so it poses no real risk. Vulnerable code present does not equal risk.

Why Application Security Teams Are Drowning in Alerts

The volume is the first problem. Jerry Gamblin's review shows record CVE volume in 2025: 48,185 CVEs were published in 2025, a 20.6% increase from 2024's 39,962.

Exposure is widespread too. Datadog shows most organizations carry exploitable vulnerabilities: 87% of organizations have at least one known, exploitable vulnerability in deployed services, affecting 40% of all services.

All of this lands on people. An IDC InfoBrief reports the hours spent triaging findings: developers spend 3.5 hours on average per week manually reviewing security scanning findings. That is time not spent shipping features.

The wording is part of the trap. Software composition analysis (SCA), the practice of scanning your open source dependencies, often flags every known flaw it sees. Most of those flaws are never exploited, so "fix all criticals and highs" buries teams in non-actionable work.

Severity Scores Alone Can't Tell You What to Fix

CVSS, the Common Vulnerability Scoring System, rates how severe a flaw is on a 0 to 10 scale. Severity is not the same as risk. A critical score on code you never run is still not urgent.

Two signals get you closer to real risk. EPSS, the Exploit Prediction Scoring System, estimates the probability that a flaw will be exploited soon. KEV, the CISA Known Exploited Vulnerabilities list, records flaws seen in active attacks.

Both help, but neither knows your codebase. J.P. Morgan's Patchmageddon analysis notes that only a small fraction are exploited: only 1.5-2.0% of reported vulnerabilities are exploited each year.

Reachability adds the environment-specific layer these scores miss. For a side-by-side view, Endor Labs compares vulnerability prioritization methods.

How Reachability Analysis Cuts Alert Noise

So how does application security vulnerability reachability reduce alerts? The workflow is mechanical, which is what makes it reliable. First, build a call graph starting from your entry points.

Second, map each CVE to the specific vulnerable function it affects. Third, check whether any path connects your code to that function.

A path can be direct or run through several layers of function calls. Reachability tools trace each hop, so an alert survives only when a real chain of calls reaches the flaw.

If no path exists, the finding is unreachable and drops down the queue. That removes the majority of findings before a human ever sees them.

Our own data shows that 90.5% of vulnerabilities are unreachable at the function level, which cuts remediation work by roughly the same amount. Endor Labs measures about 92% average noise reduction when teams prioritize open source risks this way.

Static, Dynamic, and Runtime Reachability

There are three ways to gather this evidence. Static reachability analyzes your code and call graph without running the app.

Dynamic reachability observes behavior while tests exercise the app. Runtime reachability watches what actually loads in production.

Each has trade-offs. Static analysis is fast, broad, and the workhorse for SCA, though it needs care with dynamic code. Dynamic and runtime data are precise, but they only cover the paths you actually exercised.

Reachability Levels: Function, Dependency, Container

Precision comes in levels. Dependency-level asks whether a package is used at all.

Function-level asks whether the specific vulnerable function is called. Container-level asks whether the vulnerable package is present and used inside the image.

In our experience at Endor Labs, function-level is the most precise level for SCA. It also has to follow transitive dependencies, the indirect packages your direct dependencies pull in.

Endor Labs research finds that 95% of open source vulnerabilities live in transitive dependencies. It also finds 88% of imported code goes unused, which is why manifest-only tools over-alert.

From Code to Containers: Full Stack Reachability

Most tools analyze one layer at a time and stop there. A stronger approach builds one connected call graph across first-party code, open source dependencies including transitive ones, and container images. Endor Labs calls this full stack reachability.

Siloed scanners each see one slice. At Endor Labs, we see a container scanner flag a package that code analysis already proved unreachable. We also see a code scanner miss a path that appears only once dependencies resolve.

One graph across layers helps in both directions. It removes findings that no layer can reach, which cuts false positives.

It also catches paths that cross layers, which cuts false negatives. In Endor Labs testing, this approach delivers up to 90% fewer false positives.

Stack Reachability With EPSS for Compounding Noise Reduction

Reachability and EPSS work best stacked in order. First, keep only the reachable findings.

Then rank those by EPSS, the estimated probability of near-term exploitation. The two filters compound instead of overlapping.

The math is striking. Endor Labs data on combining reachability and EPSS shows about 98% noise reduction, leaving teams to remediate an average of just 2% of reported vulnerabilities. Four of five reachable flaws still carry a 1% or lower exploit chance.

A Practical Playbook to Reduce Vulnerability Alerts

Here is a repeatable, five-step workflow you can run every release. Each step narrows the list before it reaches a developer. The goal is simple: fewer tickets, and each one worth a developer's time.

• Inventory everything: Build a complete list of first-party code, dependencies, transitive packages, and container images.
• Filter to reachable findings: Drop vulnerabilities your call graph cannot reach so humans never triage them.
• Rank by exploit intelligence: Sort the survivors by EPSS and KEV to surface real-world risk first.
• Route to code owners: Send each remaining finding to the right team with clear fix guidance.
• Measure noise and MTTR: Track the percent of alerts removed and mean time to remediate over time.

The alert math is easy to picture. Start with 1,000 raw findings.

Reachability removes about 90%, leaving roughly 100. Add EPSS ranking, and about 20 warrant real attention in this example.

Fix What's Reachable Without Breaking the Build

Prioritization is only half the job. The other half is fixing reachable flaws without breaking working software. Endor Labs offers safe upgrade paths with upgrade impact analysis that shows exactly what changed between versions.

When an upgrade is not an option, backported patches let you fix the vulnerability now and upgrade on your own timeline. Developers get a clear path forward instead of a blocked build.

Limitations and How to Evaluate a Reachability Tool

Static reachability has honest limits. It can miss dynamic language features like reflection, where a program calls its own code by name while running.

So a good tool treats "unreachable" as a high-confidence verdict and keeps it separate from "undetermined." Treat any finding you cannot analyze as undetermined, and revisit it rather than dropping it.

Use this checklist when you evaluate a reachability tool.

How Endor Labs Reduces Alerts With Reachability

For engineering teams, the first win is quieter days. Endor Labs builds a call graph across your whole application, so developers see fewer interruptions and fix issues faster. Less noise means more time shipping.

The security results follow from the same graph. Endor Labs verifies which findings are actually reachable and exploitable across code, dependencies, and container images. Across those layers, this verification cuts up to 95% of the noise at each layer.

It covers transitive dependencies and hard build environments like Bazel and C/C++, then combines that evidence with EPSS to rank what remains. Coverage gaps are surfaced transparently, so you always know what a scan could not analyze.

Fixing is part of the same workflow. Evidence-based remediation offers safe upgrades and backported patches, and AI Code Security extends the same reachability approach to code written by coding agents. This is security intelligence for agentic software development, tuned to cut work rather than add it.

Frequently Asked Questions

What is reachability analysis in application security?

It checks whether your application can actually reach and run a vulnerable piece of code. If it cannot, you can safely ignore that flaw.

How is reachability different from prioritizing by CVSS score?

CVSS rates how severe a flaw is in general. Reachability tells you whether that flaw sits on a code path your app can execute.

What's the difference between a "vulnerable" and an "exploitable" vulnerability?

A vulnerable component simply contains a known flaw, while an exploitable one is both reachable in your code and backed by real-world exploit activity.

Does "unreachable" mean there's zero risk?

No; it means very low current risk. A strong tool keeps a confirmed "unreachable" verdict separate from "undetermined" and rechecks as code changes.

What are the levels of reachability (function, dependency, container)?

Dependency-level checks if a package is used at all. Function-level checks if the vulnerable function runs, and container-level checks if the package is used inside the image.

Can reachability analysis replace my SCA or SAST tools?

No; reachability is a prioritization layer on top of SCA and SAST, using their findings to tell you which ones deserve action first.

Conclusion: Turn Alert Noise Into Action

Reachability separates the vulnerabilities your application can actually reach from the noise around them. Stack it with EPSS and evidence-based remediation, and your team can focus on the roughly 2% of findings that truly matter. That is how application security vulnerability reachability reduces alerts for teams that adopt it.

Start small: inventory one service, filter to reachable findings, and measure the drop. When you want to see full stack reachability on your own code, book a demo.