NVD is a US government database of CVE records with analyst enrichment. OSV is an open, package-focused database that aggregates ecosystem advisories in one schema. NVD changed to a risk-based enrichment model in April 2026, so many records now carry less detail. For open source work, query OSV first and use NVD and KEV as context.
What does NVD do now?
NIST's NVD page records a clear shift. On 15 April 2026 NIST said it would move to a risk-based model, enriching CVEs that meet certain criteria and labelling the rest as lowest priority. It gave the reason as a 263% rise in CVE submissions from 2020 to 2025. Records in CISA's Known Exploited Vulnerabilities catalog are to be enriched within one business day. Backlogged CVEs with an NVD publish date before 1 March 2026 move into a "Not Scheduled" category, and modified CVEs are reanalyzed only when the change materially affects enrichment data.
Earlier notices fit the same trend. In March 2025 NIST reported the backlog still growing after a 32% rise in submissions during 2024. In April 2025 it marked CVEs published before 1 January 2018 that were awaiting enrichment as Deferred.
What this means for you: a missing CVSS score or product match on a CVE is no longer a short delay. Do not build a pipeline that blocks on NVD enrichment.
What is in OSV?
The OSV.dev data page lists 18 current data sources, including the GitHub Advisory Database, the PyPI Advisory Database, the Go Vulnerability Database, the Rust Advisory Database and OpenSSF Malicious Packages. It also converts Debian Security Advisories, Alpine SecDB and NVD CVEs for open source software. It covers 29 ecosystems, among them npm, PyPI, Maven, Go, crates.io, NuGet, RubyGems and several Linux distributions. Data is exported continuously to a public bucket, with a full zip and per-ecosystem zips.
The query API has POST /v1/query, POST /v1/querybatch and a GET endpoint to fetch one record by ID. The FAQ said at fetch time that there is no rate limit and that responses are capped at 32 MiB over HTTP/1.1.
Why do version matches differ?
NVD identifies affected products with CPE names, which the OSV FAQ says make automated matching to package versions hard. OSV records an affected array with ranges of type SEMVER, ECOSYSTEM or GIT. A version is affected if it is in the versions list or inside any range. OSV also enumerates versions on import for some ecosystems so matching is exact.
Record IDs carry a database prefix such as GHSA, PYSEC, RUSTSEC, GO, MAL or DEBIAN, and an aliases field links the same issue across databases, usually to a CVE ID. Always dedupe on aliases before counting.
What does KEV add?
CISA's KEV catalog lists vulnerabilities known to be exploited in the wild. When fetched on 18 October 2026 it showed 1,748 entries. CISA encourages using it as an input to prioritization. The count is small next to the full CVE volume, which is the point: a tiny list of confirmed exploitation tells you where to start.
What can you honestly conclude?
Counts alone mislead. The sources above support three statements: submissions have grown quickly, NVD has narrowed what it enriches, and OSV matches package versions more directly. They do not support a claim about how many open source vulnerabilities exist or how fast the number grows, because that depends on definitions we did not verify. If you quote a total, quote its source and date.
What to do
- Query OSV by package and version in CI, and by ID when you triage.
- Treat NVD as supplementary, and do not block builds on missing enrichment.
- Dedupe findings across GHSA, CVE and distro IDs using aliases.
- Check each finding against KEV and raise it if listed.
- Add reachability, so a finding in code that never runs does not outrank one on a live path.
- Record the source and date of any number you publish.
Quick check
Is NVD still the place to look up every open source CVE?
It is still a record, but since April 2026 NIST enriches only CVEs that meet its criteria, so many entries lack scores or product data. Pair it with OSV.
What does the aliases field do in OSV?
It lists IDs of the same vulnerability in other databases, so you can match a GHSA entry to its CVE and avoid double counting.
Does a KEV listing mean I am affected?
No. It means the vulnerability is exploited somewhere. Check whether your version and code path are exposed.
Sources
- NIST NVD program page, notices of 15 April 2026, 2 April 2025 and 19 March 2025, fetched 18 October 2026.
- OSV.dev data documentation
- OSV.dev FAQ
- OSV schema
- CISA Known Exploited Vulnerabilities catalog, fetched 18 October 2026.
Last reviewed: 18 October 2026.
