Open source vulnerability scanners read your lockfiles, manifests or container layers, list the components they find, and match them against public vulnerability databases. Choose by data sources, ecosystem coverage, how they handle false positives, and whether results fit your workflow. Run two on the same project and compare.
What happens inside a scanner?
There are three steps. First, discovery: parse package manifests and lockfiles, and for containers read package databases in each layer. Second, identification: turn each component into a standard name such as a package URL or a CPE. Third, matching: compare names and versions to advisories.
Each step can fail. Discovery misses code that was vendored or copied. Identification can attach the wrong name. Matching depends on version ranges that data sources express differently.
The OSV project is an example of an open database and schema that records affected version ranges per ecosystem, and the osv-scanner is an open source tool that queries it. OWASP Dependency-Check is another long-standing open source project, which identifies components and matches them with known vulnerabilities. Both are examples, not endorsements, and there are other options.
What differences matter most?
Data sources. Does the tool use one database or several, and how quickly do new advisories appear? A flaw published in an ecosystem advisory may take time to reach a national database.
Ecosystem coverage. Check your actual languages, build systems and container base images, not a list of logos.
Matching quality. Name-based matching can create false positives, for example when two unrelated projects share a name. Ecosystem-specific version ranges reduce that.
Reachability and context. A report that lists every vulnerable library is not the same as one saying that the vulnerable function is called. Few open source scanners judge this well.
Output formats. SBOM export in CycloneDX or SPDX, and machine readable results such as SARIF, make integration easier.
Maintenance. Look at release cadence, open issues and the number of active maintainers.
Offline use. Some environments need to mirror data and scan without internet access.
A constructed example
Two scanners run on one Node.js service with 380 packages. Scanner A reports 41 findings. Scanner B reports 27. The overlap is 22. Reviewing the 19 only in A, the team finds 11 are real advisories B's data had not yet imported, and 8 are name collisions. Among the 5 only in B, 4 are real. The lesson is not which tool won, but that no single feed is complete, and that reviewing disagreements is how you learn each tool's blind spots.
What do scanners not tell you?
A finding is a claim about a version, not proof of exploitation. Severity scores describe the flaw in general, not your deployment. Some advisories are disputed or apply only to a non-default configuration. Plan for a short human review step for high-severity items, and record the decision so the same alert does not return next week. Track how long findings stay open, since that shows whether the scanner is driving fixes or just producing a list.
How to check or apply this
- Make a short list of your languages, package managers and container base images.
- Pick two candidate scanners that support all of them, and run both on three representative repositories.
- Compare results by advisory identifier. Review every difference by hand.
- Measure the time to scan, and where it runs: developer machine, pull request or nightly.
- Check whether it produces an SBOM, and whether you can feed results into your ticketing or dashboard.
- Decide the gate: which severity or exploit evidence blocks a merge, and how exceptions are approved.
- Keep data fresh. Update the database on every run or on a short schedule.
- Re-scan deployed artifacts, not just new commits, because new advisories appear for old code.
- Record your choice and review it yearly.
Where does Safeguard fit?
Safeguard offers dependency and SBOM scanning with reachability analysis, and a free in-browser scan at gold.safeguard.sh/scan that covers up to 100 dependencies if you want a quick comparison against your open source tool's output.
Quick check
Is one scanner enough?
Often it is a good start, but data and matching differ, so comparing two on a sample of your projects will show gaps. Pick one for the pipeline once you know them.
Why do scanners report vulnerabilities in code we never call?
Most match by package and version, not by whether your code reaches the vulnerable function. Reachability analysis or manual review is needed to tell the difference.
Sources
- OSV, open source vulnerability database
- osv-scanner on GitHub
- OWASP Dependency-Check
- OWASP CycloneDX
Last reviewed: 18 October 2026.
