NVD is the US National Vulnerability Database, which adds scores and product data to CVE records. OSV is an open aggregator that expresses vulnerabilities in a common format with exact affected package versions. For dependency scanning, OSV usually maps better to packages; NVD remains a reference for CVE enrichment. Many tools use both.
What is each source?
The National Vulnerability Database is run by NIST. It takes entries from the CVE list and adds analysis such as severity scores and weakness and product mappings. Its focus is the CVE.
OSV describes itself as helping developers identify known third party open source dependency vulnerabilities that pose genuine risk. Its infrastructure aggregates vulnerability databases that have adopted the OpenSSF Vulnerability format, and it works to ensure affected versions are accurately represented through bisection and version analysis. OSV-Scanner is its first party tool built on the OSV API.
Where do they differ in practice?
Identifier and matching. NVD ties records to product identifiers that were designed for commercial software names, which can be hard to match to a package name in an ecosystem. OSV records name the ecosystem, package and version ranges directly, so a lookup by package and version is natural.
Sources. NVD centers on CVE. OSV pulls from many ecosystem advisory databases, so it can include advisories that never received a CVE, such as some malicious package reports.
Machine format. OSV publishes a defined schema and an API meant for tooling.
Enrichment timing. NVD enrichment has at times lagged behind CVE publication. We have covered that in other posts; check current status before relying on NVD scores as your only signal.
A constructed example
Suppose a Python library has a vulnerability published by its ecosystem advisory database with affected versions 2.0 to 2.3.1. Your lockfile pins 2.2.0. A lookup by package and version against OSV returns the advisory directly. If the CVE record in NVD has not been enriched yet, there may be no usable score or product match, and a tool depending only on that would show nothing. The reverse also happens: an NVD record may carry a severity score that a given ecosystem entry lacks.
Which should you use?
Use OSV for matching your dependencies to known issues, and NVD or other sources for severity context, CWE mapping and non package software. Neither tells you whether the vulnerable code is reachable in your app. That needs separate analysis.
How to apply this
- Generate an inventory or lockfile of exact versions.
- Query by package and version, not by name alone.
- Merge records by CVE or alias so one issue is not counted twice.
- Pull severity from more than one source and note disagreement.
- Track findings with no CVE.
- Add reachability analysis to prioritize.
- Re-scan on a schedule, since data changes.
Safeguard's SBOM and dependency scanning, along with reachability analysis, are built to combine vulnerability sources and rank what matters in your code.
What are the pitfalls of mixing sources?
Duplicates are the first: the same issue may appear under a CVE ID, a GitHub advisory ID and an OSV ID, so group by aliases. Severity can differ between sources, since each scores with its own context. Version ranges may disagree too; when they do, test the actual version rather than trusting one record. Finally, a database tells you a version is affected, not whether your code calls the vulnerable function. Two projects with the same package can carry very different real risk. Record which source produced each finding so you can explain it later when someone asks why a ticket exists.
Quick check
Is OSV a replacement for NVD?
No. They overlap but serve different needs. Many scanners consult both.
Why might a vulnerability show in OSV but not NVD?
It may come from an ecosystem advisory that has no CVE, or NVD may not have processed it yet.
Sources
Last reviewed: 18 October 2026.
