Choose a reachability tool by testing five things: whether it supports your languages at the depth you need, which methods it combines, how it handles code it cannot analyse, how results reach your policy and tickets, and whether the vendor states its limits. Run it on your own repositories before you buy.
What does reachability analysis answer?
It asks whether your code can actually call the vulnerable function in a dependency. A package can contain a flaw that nothing in your application ever touches. Marking those findings lower priority is the point.
It does not replace severity or exploit data. FIRST describes EPSS as a model that estimates the probability a published CVE will be exploited in the wild in the next 30 days. CISA's Known Exploited Vulnerabilities catalog lists flaws seen exploited. Good prioritisation uses all three signals together.
What should you check first?
Language and ecosystem coverage. Support is rarely uniform. In Safeguard's docs, for example, Java, Kotlin, Scala, Python, JavaScript, TypeScript, Go, Rust, C, C++ and C# are marked GA for static and dynamic analysis, while Ruby and PHP static analysis and Swift and Objective-C are labelled preview. Ask every vendor for a table like that, with maturity per language, and compare it with your stack.
Method. Static analysis builds a call graph and looks for a path. Dynamic analysis records what runs in production and can flag vulnerable paths that never execute. Configuration analysis reads framework wiring, such as route files, to see whether code is connected. A tool with one method will miss what another sees.
Handling of unknowns. Reflection, eval and native code defeat call graphs. The safe behaviour is to mark such cases unknown and treat them as potentially reachable, not to hide them. Safeguard's docs do this. Ask any vendor what happens in the same case.
Granularity of the answer. A binary yes or no is less useful than classes. Safeguard describes four: reachable, conditionally reachable (needs a flag, route or setting that is off), unreachable, and unknown. "Conditionally" matters because a flag can be turned on next week.
How should results drive action?
A reachability label that sits in a report changes nothing. Look for these:
- A priority score or filter that combines reachability with exploit signals, so the urgent queue is short.
- Policy rules that can block on reachable, known exploited findings in production.
- Explanations for deprioritised findings, so an auditor or developer can see why something was demoted.
- Auto-fix or pull request support for the top items.
What are the honest limits?
Treat any vendor that claims perfect filtering with suspicion. Safeguard's docs say reachability is not a complete filter: data driven vulnerabilities can still be exploitable when static analysis finds no path, and paths that depend on configurations the analyser cannot enumerate may be missed. Use KEV, EPSS and runtime observation alongside it.
Also be wary of noise reduction numbers. They depend on the codebase, language mix and starting backlog. A vendor's aggregate figure tells you little about your repositories.
How do you run a fair trial?
Pick three repositories: a mature service, a messy legacy one and a polyglot one. Take 20 findings the vendor flags as unreachable and have a developer try to reach each by reading the code. Count disagreements. Then take 10 flagged as reachable and check those too. Ten minutes per finding tells you more than a demo.
What to do
- List your languages and package managers, and rank them by risk.
- Ask each vendor for per language maturity, static and dynamic.
- Ask what the tool does with reflection, eval and native code.
- Check how classes feed policy, tickets and pull requests.
- Run the trial above on three of your repositories.
- Record disagreements and ask the vendor to explain each one.
- Confirm where analysis runs, and whether source code leaves your environment.
Quick check
Does reachability analysis replace CVSS and EPSS?
No. It adds one signal about whether your code can call the flaw. Severity, exploitation likelihood and known exploitation still matter.
What should a tool do when it cannot tell if code is reachable?
Report it as unknown and treat it as potentially reachable, rather than suppressing it.
Sources
- Safeguard reachability analysis docs, fetched 18 October 2026
- FIRST, Exploit Prediction Scoring System, fetched 18 October 2026
- CISA Known Exploited Vulnerabilities catalog, fetched 18 October 2026
Last reviewed: 18 October 2026.
