Recommend reachability analysis when a team drowns in dependency CVEs. It checks whether your code can actually call the vulnerable function, so you fix the reachable ones first. Pair it with exploit data such as EPSS and the CISA known exploited list, and never treat unreachable as permanently safe.
What problem does it solve?
A dependency scanner reports every known CVE in every package in your tree. Many of those packages are used for one function, and the flaw lives in another. Teams then burn weeks patching issues no input can reach, while a reachable one waits in the same list.
Reachability analysis adds a question: does a path exist from your code to the vulnerable code? Safeguard's docs describe three forms. Static analysis builds a call graph from source, lockfile and bytecode. Runtime analysis records which functions load in production. Configuration analysis checks whether framework wiring makes the code live.
What should a buyer check?
Different products use the same words for different things. Ask:
- Which languages and ecosystems have call-graph support? Coverage varies. A tool may do Java well and nothing for your Go services.
- What does it do when it cannot decide? Reflection, dynamic dispatch and native code defeat static analysis. A careful tool marks these unknown and keeps them in the queue. Safeguard's docs say such cases are treated conservatively as potentially reachable.
- Can you see the path? A verdict without a path cannot be reviewed by a developer.
- Does it combine other signals? EPSS estimates the chance a CVE is exploited in the next 30 days. CISA's catalog lists vulnerabilities exploited in the wild. CISA says organizations should use the catalog as an input to prioritization, which is the right framing: an input, not a verdict.
- Where does the analysis run? If source code must stay inside your network, check for a local mode.
What are the honest limits?
Reachable does not mean exploited. It means your code can get to the flaw. Whether an attacker can supply the input depends on exposure, and internet-facing services deserve more urgency than internal batch jobs.
Unreachable does not mean forever. A refactor next month can add a call to the vulnerable function. Re-run the analysis on each build, and keep a record of why a finding was deprioritized.
Also beware of treating reduced alert counts as the goal. The goal is fewer exploitable flaws in production. A tool that hides findings to look quiet is worse than none.
How does a team use it day to day?
Sort the backlog into three bands. Reachable and known exploited: fix this week. Reachable and not exploited: schedule in the normal sprint. Unreachable or conditional: upgrade with routine maintenance, and monitor KEV and EPSS changes for the package.
Review the unknowns by hand once. Most turn out to be false worries, and the exceptions justify the effort.
What to do
- Generate an inventory with versions, per service.
- Turn on reachability analysis for your main languages and check which are covered.
- Add EPSS and the CISA catalog as inputs to ranking.
- Define the three bands and their deadlines in writing.
- Review unknown results by hand.
- Re-run on every build and record why anything was deprioritized.
Quick check
Can I ignore every unreachable finding?
No. A later code change can make it reachable. Keep it tracked, re-run the analysis, and upgrade during routine maintenance.
Is reachability the same as exploitability?
No. Reachability says your code can call the flaw. Exploitability also depends on whether an attacker can supply the triggering input.
Sources
- Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
- FIRST: Exploit Prediction Scoring System
- CISA: Known Exploited Vulnerabilities Catalog
Last reviewed: 18 October 2026.
