What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Exact list of supported lockfile formats and container base images: confirm against current documentation
- Scope of call graph reachability analysis: believed to cover Go and Rust, confirm current language list
- Guided remediation coverage beyond npm: confirm
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
OSV-Scanner is the reference client for OSV.dev, the open vulnerability database Google publishes. The important design decision is in the data format rather than the scanner. OSV records affected packages as explicit version ranges and commit ranges in a named ecosystem, so matching is a direct lookup on an exact package and version instead of the fuzzy name matching that CPE based tools fall back on. Fewer false positives come out the other end, and the ones that do are traceable to a specific advisory record.
The scanner reads what your package manager already wrote: lockfiles across common ecosystems, SBOM documents in SPDX and CycloneDX form, installed OS packages inside container images, and git submodule commit hashes. That last case is useful for vendored C and C++ dependencies pinned by commit, which most manifest driven tools cannot see at all. It also layers experimental call graph analysis for some compiled languages, which reports whether the vulnerable function is actually reachable from your code, and a guided remediation mode that proposes the upgrade set with the least breakage.
Where it fits
This is a command line tool a developer runs locally or a pipeline step that fails a build on a severity threshold. It needs a resolved lockfile or an SBOM to work well, so it belongs after dependency resolution rather than against raw source. There is no server, no dashboard and no ticket workflow, which makes it easy to adopt and means you supply the aggregation yourself if you are scanning many repositories.
Strengths
- Precise version range matching from the OSV schema, which cuts the false positive noise that CPE matching generates.
- Advisory data is open and inspectable, so you can check exactly why something was flagged.
- Reads SBOMs and git commit hashes, covering vendored and non manifest dependencies that other scanners skip.
- Single static binary with no infrastructure to run.
Limitations
- Coverage is only as good as OSV.dev. Ecosystems with thin advisory feeds get thin results, and there is no proprietary research layer filling gaps.
- No policy engine, reporting UI, or cross repository view. Scanning an estate means building that layer yourself.
- Reachability analysis is limited to a few languages and should be treated as a hint for prioritization, not a reason to dismiss a finding.
Who it suits
A strong default for teams that want dependable, auditable dependency scanning in CI without procurement, and for anyone who needs SBOM or commit hash based scanning. Teams that need governance workflow, waivers and executive reporting should treat it as an engine to feed something else rather than the whole answer.
Used OSV-Scanner? Recommend it under your own name and title.
Recommend this tool