Reachability analysis checks whether the vulnerable part of a dependency can actually be called by your application. For regulated teams it helps rank fixes and justify decisions, if the tool records its reasoning and runs where your data rules allow. It reduces noise but does not prove safety, so keep a human sign off.
What problem does it solve?
A software composition scan lists every known vulnerability in every dependency. Many of those flaws sit in functions your code never calls. Without reachability, teams treat the list as equal, burn time on irrelevant items, and risk missing the one that matters.
Reachability adds a question per finding: is there a path from your code to the vulnerable function? If yes, the finding is a candidate for urgent action. If not, it can wait, with the reason recorded.
The standard way to record the "not exploitable here" decision is a VEX document, a Vulnerability Exploitability eXchange statement. CISA published minimum requirements for VEX on 21 April 2023, and CycloneDX can carry vulnerability and exploitability information. A VEX record turns a quiet decision into evidence.
Why do regulated industries care more?
Three pressures apply.
- Evidence. An auditor or customer may ask why a known vulnerability was left open. "The tool said low priority" is a weak answer. "The vulnerable function is not reachable, here is the analysis and the sign off" is a stronger one.
- Timelines. Frameworks and contracts set fix windows. Spending them on unreachable findings leaves less time for real ones.
- Data location. Many regulated organizations cannot send source code to a third party service, or to a hosted language model.
NIST's Secure Software Development Framework, SP 800-218 version 1.1, gives suppliers and buyers a shared vocabulary for secure development practices, including how a vendor handles vulnerabilities in its software. Reachability evidence is one input to those conversations.
Which questions should a buyer ask?
- How is reachability determined? Static call graph analysis, runtime data, or both? Which languages and frameworks are covered?
- What is the unit of analysis? Function level reachability is more precise than package level.
- What happens with unknowns? Reflection, dynamic loading and generated code can hide paths. Does the tool mark these as unknown and not as unreachable?
- Is the decision recorded? Can you export the reasoning and a VEX statement?
- Where does analysis run? On your machines, in your cloud, or in the vendor's? Does it need a language model, and can it run without one?
- How does it fit the pipeline? Pull request, CI and IDE.
- Can you override? A reviewer must be able to mark a finding reachable or not, with a reason.
What are the honest limits?
Reachability is an analysis of code paths, not a guarantee. It can miss paths, and a flaw that is unreachable today may become reachable after a refactor. It also covers only vulnerabilities that sit in code. Misconfiguration and exposed secrets need other checks. Treat "unreachable" as "lower priority with a reason and a review date," not as "closed."
Where does Safeguard fit?
Safeguard offers reachability analysis and prioritization. It can run in Full AI mode, in Zero AI mode with no language model, or with a model you bring, and its CLI has a local runner mode that scans on your machine and pushes only encrypted results. Evaluate it on your own repositories and compare the findings it ranks first with what your team would have picked.
Try it at /demos/exploitability-check.
What to do
- Pick a repository with a known backlog of dependency findings.
- Run reachability on it and sort findings into reachable, unreachable and unknown.
- Review a sample of the unreachable group by hand.
- Record each decision with a reason and a review date, in VEX form if you can.
- Confirm where analysis runs and what data leaves your environment.
- Re-run after major refactors and dependency upgrades.
Quick check
Does "not reachable" mean safe to ignore?
No. It means lower priority with a recorded reason. Code changes can make it reachable later, so set a review date.
What is VEX?
A Vulnerability Exploitability eXchange document states whether a product is affected by a known vulnerability. CISA published minimum requirements for it in April 2023.
Sources
- CISA: Minimum Requirements for VEX
- CycloneDX: specification overview
- NIST SP 800-218, Secure Software Development Framework
- Safeguard docs: Local Runner
Last reviewed: 18 October 2026.
