Most free dependency scanners match package versions to known vulnerabilities and stop there. They tell you a vulnerable package is present, not whether your code calls the affected function. You can answer that by hand for a few findings, but it does not scale.
Presence versus reachability
A scanner like OSV-Scanner matches your dependency list against the OSV database. That is a statement about what is in your build. Reachability is a separate question about whether execution can get to the vulnerable code from your application. A package can be present and never called.
The manual method
For one high severity finding:
- Read the advisory to find the affected function or feature.
- Search your code, and your dependencies' code, for calls to it.
- Check configuration. Many issues need a particular option enabled.
- Record the outcome as an exploitability statement. VEX exists for this, and CycloneDX describes it as conveying whether a vulnerable component can actually be exploited in the product where it is used.
- Revisit when the code changes.
Why it does not scale
Transitive dependencies make the search deep. Dynamic languages hide call paths. Each decision goes stale when code changes. At fifty findings a week, the manual route consumes the time it was meant to save.
What to do with limited time
| Situation | Approach |
|---|---|
| Few findings | Analyse by hand and record VEX statements |
| Many findings, small team | Prioritise by known exploitation (KEV) and EPSS first |
| Many findings, audit pressure | Evaluate tooling that computes reachability |
CISA's catalog of known exploited vulnerabilities and FIRST's daily EPSS scores are free signals that sit alongside reachability, not instead of it.
An honest caveat
Reachability results can be wrong in both directions, especially with reflection and dynamic loading. Treat unreachable as lower priority, not as never.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
Record what you learn
When you investigate a finding by hand, write the conclusion where the next person will find it: the finding, the reasoning, the date and the code version. A short note beats redoing the work next quarter. If the same package keeps appearing, the notes show whether the pattern is real or whether your analysis keeps coming out the same way.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the list before and after reachability, and note which findings drop out and why.
Quick check
Is a vulnerable package always a vulnerable application?
No. The vulnerable code may never be called, but confirm before you deprioritise it.
What free signals help prioritise?
Known exploited status from CISA KEV and EPSS scores from FIRST, both published openly.
Sources
- OSV-Scanner documentation
- CycloneDX VEX capability
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS
Last reviewed: 19 October 2026.
