Safeguard
Research•

What do NVD and OSV actually tell us about open source vulnerabilities?

NVD is a government database that adds scores to CVE records. OSV tracks which package versions are affected. Neither is a full census. A plain guide.

Safeguard Security Team
4 min read

NVD and OSV are two different public lists of known vulnerabilities. NVD, run by NIST, enriches CVE records with scores and product data, and it has a growing backlog. OSV, run as an open project, records exactly which open source package versions are affected. Neither counts every flaw that exists, only the ones reported.

This is the non-engineer version. If you are a buyer, board member or compliance lead, you will see numbers from these databases quoted in reports. Here is what they measure and where they mislead.

What is NVD?

The National Vulnerability Database is the US government repository of vulnerability data. A vulnerability gets a CVE identifier from the CVE program. NVD then adds analysis, such as a severity score and the products affected. That second step is called enrichment, and it takes people.

What is OSV?

OSV is an infrastructure project that helps developers find known vulnerabilities in third party open source dependencies. Its documentation says it aggregates vulnerability databases that use the OpenSSF Vulnerability format, and adds version analysis so affected versions are recorded accurately. It exposes an API, for example a query endpoint, and a first party scanner uses that data.

The practical difference: NVD answers "what is this CVE and how bad is it?" OSV answers "which versions of this package are affected?" For a developer checking a lockfile, the second question is the useful one.

What changed recently at NVD?

NIST's own NVD page lists several notices. Read these as primary evidence:

  • On 15 April 2026, NIST said it would prioritize CVEs in CISA's Known Exploited Vulnerabilities catalog, federal-use software and critical software. Others would be labeled "Lowest Priority" and not scheduled for immediate enrichment, and users can request enrichment by email.
  • Also on 15 April 2026, backlogged CVEs published before 1 March 2026 moved to a "Not Scheduled" category, to be enriched as resources allow.
  • In March 2025, NIST said the backlog was still growing, with submissions up 32% in 2024.
  • In April 2025, pre-2018 CVEs awaiting enrichment were marked as Deferred.
  • In April 2026, NIST found approximately 4,500 CVE records with an incorrect numerical CVSS v4.0 score, most scored too high, and scheduled a correction script.

What this means: a missing score in NVD often means "not analyzed yet," not "not dangerous." Any report that ranks risk only by NVD severity inherits that gap.

What is the KEV catalog?

CISA's Known Exploited Vulnerabilities catalog is described as the authoritative source of vulnerabilities exploited in the wild. When we fetched the page on 18 October 2026 it listed 1,748 entries. CISA says organizations should use it as an input to vulnerability management prioritization. It is a short list of confirmed exploitation, which makes it a better "fix first" signal than a long list of everything.

What can you safely say from this data?

  • Public databases hold known vulnerabilities, not all vulnerabilities.
  • Counts depend on reporting behavior, tooling and funding, so year to year comparisons are weak evidence of "more insecure software."
  • Severity scores describe a flaw in the abstract, not your exposure.
  • A vulnerability can sit in one database before another has complete data about it.

We are deliberately not quoting total CVE counts or ecosystem percentages here, because we did not confirm figures from a primary source for this post. If you want to cite one, pull it live from the NVD dashboard or the OSV API and note the date.

What to do

  1. When a report cites vulnerability numbers, ask for the source and the date.
  2. Use more than one source: NVD or CVE for the record, OSV for package versions, KEV for confirmed exploitation.
  3. Treat a missing NVD score as unknown, not safe.
  4. Prioritize by exploitation evidence and whether the vulnerable code is used, not by severity alone.
  5. Rescan on a schedule, since entries change after publication.
  6. Keep an inventory of your own dependencies, because the databases cannot tell you what you run.

Quick check

Is NVD a complete list of vulnerabilities?

No. It lists reported CVEs, and NIST's notices say many awaiting enrichment are not scheduled for immediate analysis.

Why use OSV if NVD exists?

OSV records affected package versions precisely and has an API built for dependency checks, which suits developers matching a lockfile.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.