Reachability analysis checks whether your application can actually call the vulnerable code inside a dependency. A scanner builds a call graph from your code into the library and labels each finding reachable or not. It helps you fix the findings that matter first, but it is not proof of safety.
Safeguard publishes this guide and sells a competing product, so we describe other tools only from their own documentation.
Key takeaways
- Version matching says a vulnerable package is present. Reachability asks whether your code uses the vulnerable part.
- "No path found" is not the same as "safe". Static analysis cannot prove a path does not exist.
- Language support varies by tool, and transitive dependencies are often treated differently.
- Use reachability to order the work, not to close findings without review.
What is reachability analysis in SCA?
It is a way to rank vulnerable dependencies by whether your code touches the flawed function. Snyk's documentation says it shows whether your application calls code elements, meaning functions, classes or modules, tied to a vulnerability, which indicates how likely exploitation is in your context.
Semgrep defines it as whether a vulnerable code pattern from a dependency is used in the codebase that imports it.
Why do scanners need it?
Most vulnerable dependencies sit in code your application never runs. A scanner that matches only versions will list all of them with the same urgency. That produces long lists, and developers learn to ignore long lists.
Reachability narrows the list to findings with a route from your code to the flaw, so the first pages of the backlog are the ones worth reading.
How does it work?
The common recipe has three steps.
- Identify the vulnerable code in the library, often the function changed by the fix.
- Build a call graph from your application into its dependencies.
- Check whether a path connects your code to that function.
Snyk says it links each vulnerability to the maintainer's fix commit, analyzes the related code elements, and analyzes the call graph between your application and its open source dependencies, without building the application. Semgrep matches code patterns, and writes rules for the critical and high severity CVEs in languages it fully supports.
Click through it at your own pace, or open it full screen.
What do the labels mean?
Tools use different words, so read the definitions.
| Vendor | Label | Meaning as documented |
|---|---|---|
| Snyk | Reachable | A direct or indirect path was found from your application to the vulnerable code |
| Snyk | No path found | No path was found, which does not mean the vulnerability is unreachable or unexploitable |
| Snyk | Not applicable | Reachability is not supported for this vulnerability |
| Semgrep | Reachable | A matching pattern exists; some findings are conditionally reachable and need manual review |
| Semgrep | Unreachable | The vulnerable package or code is not used |
| Semgrep | No reachability analysis | A vulnerable version is in use but no relevant rule exists |
Which languages are covered?
It depends on the tool and changes over time. As of 19 October 2026, Snyk's page lists reachability as generally available for Java with Maven and Gradle, JavaScript and TypeScript with npm, Yarn and pnpm, and Python with pip, poetry and pipenv, with C# in early access. Semgrep's page says it covers generally available languages and links to a list. For other languages it falls back to version based detection labeled no reachability analysis.
Semgrep also states that transitive dependencies get vulnerability scanning but not reachability analysis, except when their mere inclusion makes them vulnerable. Check how any tool treats indirect dependencies, since that is where most findings sit.
What are the limits?
Reachability is an estimate. Four limits to keep in mind:
- Static analysis can show a path exists but cannot prove none exists.
- Dynamic features such as reflection and plugins can hide paths.
- Rules or analysis may not exist for every CVE.
- A reachable finding in unused deployment configuration may still be low risk, and an unreachable one may become reachable after a code change.
Safeguard's SCA includes reachability analysis alongside SBOM generation and import, and you can first run the free in-browser scan on a manifest to see what version matching alone reports.
How should I use it?
- Fix reachable findings first, then known exploited ones. The Gold registry at gold.safeguard.sh shows CISA KEV status.
- Keep non-reachable findings visible, with a review date, instead of deleting them.
- Rerun after large refactors, since new code can open new paths.
- Ask any vendor which languages, which package managers and which dependency depths its reachability covers.
Frequently asked questions
Is reachability analysis the same as exploitability?
No. Reachability says your code can call the vulnerable function. Exploitability also depends on inputs, configuration and attacker access.
Can I ignore findings marked unreachable?
Not safely without review. Snyk's documentation says no path found does not mean the vulnerability is unreachable or unexploitable.
Does reachability need a build?
It depends on the tool. Snyk states its analysis runs without building the application.
Do free SCA tools include reachability?
Semgrep's pricing page lists reachability analysis on its Free edition. The open source scanner pages we read did not describe it.
Does it cover transitive dependencies?
Coverage varies. Semgrep says transitive dependencies are scanned for vulnerabilities but not analyzed for reachability, with limited exceptions.
Sources
Last reviewed: 19 October 2026.
