Your scanner just flagged 5,000 vulnerabilities. Lucky for you, likely less than 1/10 of them can be exploited in your code. Unfortunately, the report does not tell you which ones, so your team burns days chasing risks that were never real.
Reachability analysis solves this problem.
Reachability analysis is a technique that checks whether your application can reach and run a vulnerable code function in a direct or transitive dependency. It traces the execution paths in your code to separate the vulnerabilities that matter from the ones that never run, which cuts the false positives that drown most security teams.
The timing is not subtle. Researchers published more than 40,000 new CVEs in 2024, a record, and 2025 pushed past 48,000. No team can fix that volume, and traditional scanners make it worse by flagging every CVE whether or not it runs.
Reachability analysis is how security teams turn that flood into a short list of real risk.
What Is Reachability Analysis?
Reachability analysis answers one question: can an attacker reach the vulnerable code? To answer it, the analysis builds a call graph of your application, a map of which function calls which, and traces the execution paths from your code's entry points to the vulnerable function inside a dependency. If a path exists, the vulnerability is reachable. If none does, it cannot run, and it drops off your priority list.
This is a different method from traditional scanning. A scanner matches the packages in your project against a database of known CVEs and reports every match. It never checks whether your code calls the vulnerable part of the package. Reachability analysis does. Take Log4j: the vulnerability lives in a specific JNDI lookup method. If your application never calls that method, an attacker cannot exploit the CVE in your code, even though the vulnerable package sits in your dependency tree. A scanner flags it as critical. Reachability analysis marks it unreachable and moves on.
Static vs. Dynamic vs. Runtime Reachability Analysis
Reachability analysis comes in three approaches, and each trades accuracy, coverage, and overhead in a different way.
Static Reachability Analysis
Static analysis reads your source code and bytecode without running it. It builds the call graph by parsing the code and following control flow, which gives it complete coverage: it can find every theoretical path from your code to a vulnerable function, and it adds no runtime overhead. Its limit is that it cannot see behavior that only appears at runtime, such as reflection or dynamic dispatch, so it can flag paths that never execute in practice.
Dynamic Reachability Analysis
Dynamic analysis watches the application while it runs, using instrumentation or techniques like eBPF to observe which paths execute. It captures real runtime behavior and handles the dynamic features static analysis misses. Its limit is the mirror image: it only sees the paths your tests exercise, so its accuracy depends on test coverage, and the instrumentation adds overhead.
Runtime Reachability Analysis
Runtime analysis monitors the application in production, often through observability platforms or runtime agents, to record what the code does under real load. It gives you ground truth about what runs in production. Its limits are that it is reactive rather than preventive, it raises privacy and security questions about production monitoring, and it can miss the edge cases that seldom execute.
Five Types of Reachability Analysis
The approaches above describe how the analysis runs. Type describes what it measures. Endor Labs groups reachability analysis into five types, from the fine-grained function level up to broad internet exposure. Each answers a different slice of the same question: is this vulnerability reachable?
Function-Level Reachability
This is the most precise type. It traces whether your code calls the specific vulnerable function inside a direct or transitive dependency, not just whether the package is present. The Log4j case is the classic example: the CVE matters only if your code reaches the vulnerable lookup method. Function-level analysis delivers the highest noise reduction, and it depends on a database that maps each CVE to the exact functions it affects across versions, which Endor Labs builds through program analysis.
Dependency-Level Reachability
This coarser type asks whether your code uses a vulnerable dependency at all, rather than which function it calls. It is less precise than function-level analysis but simpler to run, and it still cuts real noise by excluding dependencies your code never imports and test or development dependencies that never ship. It also surfaces phantom dependencies: packages your code uses but never declares in a manifest.
Package Baselining
Package baselining watches how a third-party package behaves and flags deviations from its normal pattern. The intuitive example is Log4j: it should call the file system, not execute code or open network connections. When a package steps outside its baseline, the analysis notifies or blocks it. This works as a prioritization and detection method across both dependencies and containers.
Package Usage in Containers
This type extends reachability into the container image. A container ships with OS packages and base-image libraries, most of which your application never invokes. Package-in-container analysis identifies which of those packages your application uses, so you fix the ones that matter instead of patching hundreds of unused system libraries. This is what makes a target like the FedRAMP 30-day patching window reachable without drowning the team.
Internet Reachability
This type asks whether a vulnerable service faces the internet or sits behind your network. It combines network topology with vulnerability data to rank external attack surface first. A reachable vulnerability on an internet-facing service is a different order of risk from the same flaw on an internal-only service, and internet reachability makes that distinction.
Why Most Reachability Analysis Falls Short
Plenty of tools claim reachability analysis, so it's important to understand which approach and which type they are delivering, and if that is enough for you. For example, many vendors will claim to offer reachability analysis, but cannot see past your direct dependencies. That means they can't deliver reachability analysis for most of your application code!
Incomplete call graphs are one of the most common reasons reachability analysis falls short. A tool that misses indirect calls, reflection, or dynamic dispatch builds a partial graph, and a partial graph both flags paths that do not exist and misses paths that do. Many tools also stop at the code layer and never analyze container and OS packages, so you leave the container half of your risk unmeasured.
Some return a binary reachable-or-unreachable verdict with no exploitability context, which is thin evidence for a hard remediation call. Others break on complex build systems like Bazel or languages like C++, and report a clean result rather than admit the gap. And many produce a verdict with no evidence: no call chain you can inspect, no way to reproduce the finding. A reachability claim you cannot verify is a claim you cannot trust.
How to Evaluate Reachability Analysis in Your Security Stack
Test a reachability tool against your own code, not a demo repo. A few criteria separate real analysis from a marketing label.
Check accuracy in both directions: the false-positive rate, so the tool is not still flooding you, and the false-negative rate, so it is not missing real paths. Confirm language and framework coverage across your whole stack, including the hard cases.
Demand evidence: can the tool show you the call path that makes a finding reachable, so you can verify it by hand? Weigh integration depth, from the IDE to production, and the performance cost of running the analysis. And judge the remediation guidance, because knowing a vulnerability is reachable is only useful if the tool helps you fix it. One test cuts through the marketing: run the tool on a CVE you know is unreachable in your code, and see whether it agrees.
Keep in mind that less vulnerabilities isn't always the right outcome when evaluating reachability analysis. Inaccurate tools that attempt to hide their flaws can deliver false negatives, meaning they have fewer total vulnerabilities. That's why it is so important to evaluate call path evidence to confirm which tool is delivering the most true positives.
Full-Stack Reachability Analysis with Endor Labs
Most reachability stops at the code layer. Endor Labs evaluates it across the full stack: first-party code, open-source dependencies, and container images, in one unified code context graph. That cross-layer view is what lets it connect a finding in a container back to the source code, and it reports function-level reachability with the evidence attached, a call chain you can inspect and reproduce.
The payoff is precision. Function-level reachability filters out the vulnerabilities that never run, and customers report reductions in the range of 80 to 99 percent against tools that match on package names alone.
But the number is not the point. The point is evidence: every reachable finding comes with the path that proves it, so a developer can trust the verdict and an auditor can check it.
Reachability pairs with upgrade impact analysis so the fix ships without breaking the build, which turns a short list of real risk into a short list of safe fixes. Reachability is the foundation the whole agentic remediation model rests on.
Reachability Analysis Is Table Stakes: Evidence Is the Differentiator
Reachability analysis has crossed from differentiator to baseline. A few years ago, tracing whether a vulnerability was reachable set a tool apart. Now buyers expect it, and the bar has moved. The new differentiator is not whether a tool does reachability, but how well: the quality of its evidence, the breadth of its coverage across code and containers, and the strength of the remediation it offers once it names the real risk.
That bar will keep rising. As AI coding assistants generate more code and more dependencies, the volume of vulnerabilities climbs, and precise, evidence-backed reachability becomes more critical, not less. The teams that win will treat reachability as the starting line, and judge their tools on the evidence they can show and the fixes they can ship, regardless of their luck.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: