Compare open source dependency scanners on how they identify components, where their vulnerability data comes from, which ecosystems and lockfiles they read, whether they work offline, whether they check reachability, what they send over the network and how they handle fixes. Counting findings alone tells you little.
Why raw finding counts mislead
Two scanners run on the same repository can report very different numbers. One may match by inferred product name, another by package ecosystem and version. One may include development dependencies, another may not. More findings is not better, and fewer is not better either. You have to know what each one is claiming.
The project pages for two widely used open source scanners show how different the design choices can be.
Seven questions
1. How does it identify a component? OWASP Dependency-Check gathers evidence and infers a CPE, then lists matching CVEs. OSV-Scanner checks package names, versions and ecosystems against the OSV database. Those are different matching methods, and each has its own failure modes.
2. Where does the data come from? Dependency-Check lists NVD feeds plus sources for specific technologies. OSV-Scanner uses the OSV.dev API as its primary source, with deps.dev for supplementary data. Data source affects what is known and how fast.
3. What does it read? OSV-Scanner's page cites 11 or more language ecosystems and 19 or more lockfile types, and includes vendored C and C++ detection and layer aware container scanning. Check your own languages against any list.
4. Can it run offline? OSV-Scanner has an offline mode against a local database after an initial download. Dependency-Check needs an initial download of ten minutes or more, then a small update at least every seven days. Air gapped teams care about this.
5. Does it check reachability? OSV-Scanner describes optional call analysis that checks whether a vulnerable function is actually used, to cut false positives. Ask the same of any tool, and check which languages it supports.
6. What does it send out? OSV-Scanner's page says it sends package names, versions, ecosystems and file hashes, and states it does not send source code. Read the equivalent statement for any tool before running it on private repositories.
7. What does it do about fixes? OSV-Scanner has an experimental guided remediation command with several strategies, and warns that it can run package manager scripts on untrusted projects. Treat any automated fix feature that way until you have read what it executes.
A fair test
Pick two or three repositories you know well. Plant a known vulnerable version in one. Run each scanner with default settings, then record: found the planted issue, total findings, findings you could confirm in ten minutes, and time to run. Our guide to deduplicating findings across scanners helps when you run more than one.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how findings change once reachability is taken into account, and compare that with raw counts.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning with reachability analysis. The free scan at gold.safeguard.sh/scan gives you one more result to compare against.
Quick check
Is the scanner with more findings more thorough?
Not necessarily. Matching method, scope and noise all change the count.
What is the quickest fairness test?
Plant a known vulnerable dependency in a repository you know and see which tools report it.
Sources
Last reviewed: 19 October 2026.
