OSV-Scanner: vulnerabilities with a source of truth
Actualizado: 2026-05-03
OSV-Scanner is the Google tool that directly queries the open OSV.dev database to identify vulnerabilities in project dependencies. At first glance it looks like any other dependency scanner, and indeed the output is similar. The difference lies beneath, in how vulnerability data is represented and how cross-referencing with real dependencies happens. After two years using it on several projects, this article collects why this structure produces less noise than other tools and where friction remains.
Key takeaways
- Version-based scanners generate many false positives because CVE affected-version lists are often imprecise or generic.
- OSV represents each vulnerability with precise commit or semantic version ranges, enabling deterministic comparisons.
- OSV-Scanner supports the most common manifests: npm, Python, Go, Ruby, PHP, Rust, Maven, Gradle; also container images and SBOMs in SPDX or CycloneDX.
- The most valuable CI integration is failing only on new vulnerabilities introduced by the current change, not on preexisting ones.
- The scanner is an important part of a system, not the whole system.
The version-based scanner problem
Many dependency scanners work by comparing the version you use against a list of affected versions for each CVE. That sounds reasonable but generates a surprising amount of false positives. Reasons are several: CVE affected-version lists are often imprecise, Linux distributions backport patches without changing the public package version, and an advisory may apply only to certain configurations the scanner doesn’t distinguish.
The practical result is familiar to any team: dependency scanners produce hundreds or thousands of alerts, a mix of real and false, and filtering the real ones consumes so much time that many teams end up ignoring the scanner. Signal is lost in noise.
OSV as structured format
The idea behind OSV is to change how vulnerability data is represented. Instead of free-prose advisory with a vague list of affected versions, each vulnerability in OSV has a structured format with precise commit or semantic version ranges, stable identifiers for each package and ecosystem, and cross-references to original advisories. This structure allows deterministic comparisons.
A concrete example: an OSV advisory specifies exactly that versions between 1.2.0 and 1.4.5 are affected, in exact SemVer. If your project uses 1.4.6, the comparison is deterministic: not affected. No room for ambiguity.
OSV.dev aggregates advisories from multiple sources while keeping this structure: GitHub Security Advisories, the National Vulnerability Database, ecosystem-specific sources like RustSec or PyPI Advisory Database.
How OSV-Scanner works
OSV-Scanner takes the dependency manifest of your project, resolves exact versions, and queries OSV.dev for each package and version combination. The query returns the list of OSV advisories that apply exactly to those versions. There is no heuristic version matching nor free interpretation: if it appears in the response, it applies.
The scanner supports the most common manifests: npm’s package-lock.json, Python’s requirements.txt and poetry.lock, Go’s go.mod and go.sum, Ruby’s Gemfile.lock, PHP’s composer.lock, Rust’s Cargo.lock, Maven’s pom.xml, Gradle’s gradle.lockfile. It can also scan container images and SBOMs in SPDX or CycloneDX format.
Practical CI use
CI integration is one of the places where it shines most. OSV-Scanner is a static binary runnable in any environment. The most useful criteria in practice are two:
- Fail if any vulnerability is listed in KEV, because that indicates active exploitation in production.
- Fail if vulnerabilities introduced by the current change appear, not on preexisting ones. This is much more useful because it lets the baseline advance without every existing security fix blocking all commits.
Real limits
Three areas where OSV-Scanner keeps improving but isn’t yet enough:
- Runtime-based scanner reach: works on static declarations: manifests and SBOMs. Doesn’t detect dynamically loaded dependencies or native system libraries.
- Lack of context on whether a vulnerability affects your concrete use: a CVE in an XML function of a library you only use for JSON doesn’t affect you in practice, but OSV-Scanner will still report it.
- Prioritization ecosystem: reports vulnerabilities but doesn’t order them by real risk. Turning a vulnerability list into a prioritized work queue still needs a layer on top.
Conclusion
Alert fatigue is the enemy of real security. OSV-Scanner attacks that problem at the root, using structured data instead of version heuristics. For teams today with a dependency scanner producing hundreds of ignored alerts, migrating to OSV-Scanner usually reduces noise to a manageable fraction without losing real coverage.
