OSV vs NVD: OSV Scanner and NVD Coverage Compared

What OSV is

OSV (Open Source Vulnerabilities) is a schema and aggregation project, originally started by Google, for open-source vulnerability data. Rather than one central team analyzing every CVE, OSV ingests advisories directly from the ecosystems that produce them — GitHub Security Advisories, PyPA, RustSec, Go's vulnerability database, and Linux distribution security trackers among others — and normalizes them into a common JSON format with precise affected-version ranges per package. Our guide to the OSV API covers the schema and query mechanics in depth.

The OSV Scanner tool

The database is separate from the tooling that reads it. Google also maintains OSV-Scanner, an open-source command-line scanner that queries the OSV database directly. Point the OSV Scanner at a lockfile, an SBOM, a source directory, or a container image and it resolves each dependency, then matches it against OSV's per-ecosystem version ranges using the same free OSV API described above.

Because the OSV Scanner sources its findings from OSV alone, its coverage inherits OSV's scope: strong for npm, PyPI, Go, crates.io, and Linux-distro packages, but it will not surface a CVE that only NVD's CPE matching knows about. That single-source dependency is the exact trade-off this comparison is about — any scanner is only as complete as the databases behind it.

What NVD is

The National Vulnerability Database is run by NIST and works differently: it does not create CVE records (MITRE's CVE program does that), but it enriches them — attaching a CVSS severity score, CWE weakness classification, and CPE identifiers that name exactly which products and version ranges are affected. That CPE data is what lets a scanner match a CVE to a specific piece of software programmatically. We cover the mechanics in Understanding the NVD and CVSS.

Capability comparison

NVD's real strengths

NVD has run for two decades and remains the most widely recognized vulnerability database in compliance and procurement contexts. Its CPE matching is not limited to open-source packages — it covers commercial software, operating systems, firmware, and hardware, which OSV does not attempt to track. For organizations that need to point to a well-established, government-run authority in an audit, NVD carries institutional weight that a newer, distributed project has not yet accumulated.

OSV's real strengths

OSV's distributed model means there is no single team that has to review every vulnerability before it becomes usable. Each ecosystem publishes its own advisories with version-range precision that a general-purpose CPE identifier often cannot express as cleanly — “affected versions >=1.2.0, <1.2.7” directly, rather than requiring a scanner to interpret a CPE range. Because publication does not route through one central bottleneck, OSV coverage of open-source ecosystems has generally kept pace with the volume of advisories those ecosystems produce.

Where the two diverge in practice

The practical divergence shows up as coverage gaps in each direction. A CVE in a system package or commercial product with no open-source ecosystem advisory may exist in NVD via CPE matching but never appear in OSV at all. Conversely, a vulnerability in an actively maintained npm or PyPI package might be published to OSV within hours of disclosure, while the same CVE waits for NVD's enrichment queue before it is CPE-matchable.

This is exactly the gap that multi-source scanning is built to close. In our 2026 benchmark, scanners that match against a single aggregated database reported far fewer findings than a scanner querying multiple sources in parallel — 10 findings on ubuntu:24.04 from a single-database tool versus 1,365 from one that also queries OSV, NVD, and Red Hat OVAL together. Some of that gap is duplicate coverage across sources, but a meaningful share is vulnerabilities one source has and the others do not. Our CVE database comparison breaks down coverage by source in more detail, including GHSA and Red Hat OVAL.

Which should you rely on?

• Rely on OSVfor fast-moving open-source ecosystem coverage — npm, PyPI, Go modules, crates.io, and Linux distribution packages — where version precision and publication speed matter most.
• Rely on NVD when you need CPE-based matching for software outside open-source ecosystems, or when a compliance framework specifically references NVD as a data source.
• Do not rely on just one. Every real-world container or codebase mixes open-source packages with system-level and sometimes commercial components, which means both matching models are relevant at once.
• Check what your scanner actually queries.A tool that advertises “CVE scanning” without specifying its sources may be leaning on only one of these, silently narrowing what it can find.

How ScanRook uses both

ScanRook queries OSV and NVD in parallel for every package it identifies, plus Red Hat OVAL for RHEL-family images, rather than picking one as primary. Each finding is tagged with the source that produced it and a confidence tier based on installed-state verification, so when OSV and NVD disagree — or when only one of them has a given CVE — you can see that directly instead of inheriting one database's blind spot as if it were the whole picture.

Frequently asked questions