Article · Vulnerability scanning
OSV vs CVE for dependency scanning
“OSV or CVE?” is one of those comparisons that dissolves once you look at it: they are not two competing databases, they are two different layers. CVE gives a vulnerability a name. OSV says which package versions it affects. Only the second one can be matched against your dependency tree — and that distinction quietly decides what your scanner is capable of finding.
Updated 14 Aug 2026 · by the depproof team
Two systems, two jobs
A CVE ID is an identifier. A CVE Numbering Authority — a
vendor, a project, or a coordinating body — assigns
CVE-YYYY-NNNNN to a specific vulnerability so that everyone
discussing it is discussing the same thing. The
National Vulnerability Database (NVD) then enriches many
of those records with a severity score, a weakness classification, and a
description of the affected products. That system is what makes it
possible for a customer questionnaire, a pen-test report, and a vendor
bulletin to all refer to one issue unambiguously.
OSV is a different kind of artifact: an open data format for describing vulnerabilities in open-source packages, plus a database that aggregates records in that format from many upstream sources — among them the GitHub Advisory Database (GHSA), the PyPA advisory database for Python, the Go vulnerability database, RustSec, fuzzing-derived findings, and feeds of known-malicious packages. Every record states the ecosystem, the package name, and the version ranges affected, and lists the CVE ID as an alias where one exists.
- CVE answers “which vulnerability are we talking about?” — a name, a description, a severity.
- OSV answers “does this version of this package have it?” — the question your lockfile poses.
The mismatch that matters: CPE vs package coordinates
Here is the practical heart of it. NVD describes affected products using
CPE
— “a structured naming scheme for information technology systems,
software, and packages,” maintained as a curated dictionary of official
product names. It works reasonably well for “Acme Server 4.2”. It works
badly for
pkg:maven/org.example/lib@1.2.3, because package registries
never adopted it and nothing in a POM or a lockfile emits one.
So a scanner working from CVE and CPE data alone has to guess which registry package a CPE string refers to. That guess fails in both directions: it invents findings for a package that merely shares a name with something else, and it misses real ones where no CPE was ever recorded for the artifact you actually ship. Neither failure is visible in the report.
Package-keyed data removes the guess. An advisory that says “this ecosystem, this package name, these version ranges” lines up directly with what dependency resolution already produced — no translation layer, no name matching, no heuristic in between.
Coverage differs in both directions
It is tempting to assume one database is a superset of the other. Neither is.
- Many package advisories never get a CVE. A maintainer fixes a security bug, records it in the ecosystem’s advisory database, and no CVE is ever requested. It is a real, documented vulnerability in a package you may depend on — and it is invisible to anything keyed strictly to CVE IDs.
- Malicious packages don’t fit the CVE model at all. A typosquatted or hijacked package isn’t a flaw in software you chose; it’s hostile code that arrived through the registry. That category is tracked in open ecosystem feeds and is one of the fastest-moving supply-chain risks — and it is not what the CVE system was designed to catalogue.
- Most CVEs have nothing to do with your dependencies. The CVE corpus spans operating systems, firmware, network appliances, industrial equipment. For dependency scanning, the vast majority of it is noise you need filtered out — which is exactly what an ecosystem-scoped database does by construction.
Freshness, and what the NVD stopped doing
There is a timing problem too — and in 2026 it stopped being a queue and became a policy. A CVE ID is assigned at one moment; the enrichment that makes it machine-usable — severity score, weakness class, affected-product data — is added later, by a separate process.
On 15 April 2026, NIST announced that the NVD would no longer enrich most CVEs. Citing a 263% rise in submissions between 2020 and 2025, it now prioritises three categories: vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog, those affecting federal government software, and those in software deemed critical under Executive Order 14028. Everything else is still listed in the NVD, but flagged “Lowest Priority — not scheduled for immediate enrichment” (NIST, 15 April 2026).
Read as a dependency-scanning problem, that is stark: for an ordinary open-source library in your lockfile — not federal software, not on the KEV list — an official NVD severity score may now simply never arrive. It follows an earlier warning from a different direction: in April 2025 the CVE Program’s contract came within a day of lapsing before CISA exercised an extension (the CVE Program; contemporaneous reporting). Both point the same way: one centralised pipeline is a single point of failure.
Aggregated ecosystem data routes around that. Records flow from the upstream sources that publish them — the maintainers and ecosystem security teams closest to the package — rather than waiting on one downstream analysis queue. The CVE ID still arrives when it is assigned; it just isn’t the gate on whether you can be told at all.
What this means for your scanner
The takeaway isn’t “prefer OSV to CVE.” It’s that a dependency scanner should be built on package-keyed data and report CVE IDs, not the other way round:
- Detect on package coordinates. Ecosystem, name, version — matched against your resolved tree, with no CPE guesswork in the middle.
- Report the CVE ID whenever one exists. That is the identifier your customers, auditors and ticketing system speak. A finding without it is harder to triage and impossible to correlate.
- Prefer data you can audit and take with you. Open advisory records can be inspected and re-queried by any tool; proprietary findings can’t be verified independently and don’t survive a change of vendor.
- Keep an inventory, not just a verdict. A CycloneDX SBOM lets you re-check the estate when the next advisory lands, instead of rescanning from scratch and hoping the same coverage held.
This is why depproof screens your resolved dependencies against OSV advisory data and reports the CVE ID alongside each finding — open data underneath, the standard identifier on top, and no proprietary database holding your evidence.
What neither database can tell you
Two honest limits, and they apply to commercial databases just as much.
First: presence is not exploitability. A match means an affected version is somewhere in your tree. It does not mean the vulnerable code path is reachable from your application, or that a control you already run doesn’t neutralise it. That determination is engineering judgement, and the responsible thing is to record it — a waiver with a justification, an owner and an expiry, and VEX when downstream consumers need to know whether you are actually affected.
Second: no database can rescue a bad input. If the scanner read a file that doesn’t contain your transitive dependencies, the advisory data underneath is irrelevant — there was nothing to match against, and the report comes back clean. A confidently empty result is the failure mode that no amount of database quality can fix.
Frequently asked questions
What is the difference between OSV and CVE?
CVE is an identifier system: a CVE ID is a unique name for one vulnerability, assigned by a CVE Numbering Authority and catalogued by the CVE Program, with the National Vulnerability Database (NVD) historically adding severity, weakness classification and affected-product metadata. OSV is a vulnerability database and an open data format built specifically for open-source packages: each record states the ecosystem, the package name, and the exact version ranges affected. CVE answers "which vulnerability is this?"; OSV answers "which versions of which package are affected?" — the question a dependency scanner has to answer.
Does OSV replace CVE?
No, and it is not designed to. OSV records carry CVE IDs as aliases, so a finding sourced from OSV normally still names the CVE. The two work at different layers: CVE remains the shared vocabulary you use to talk to customers, auditors and vendors, while OSV is the machine-readable layer that maps a vulnerability onto the package versions in your lockfile. A good scanner uses both — package-level data to detect, CVE IDs to communicate.
Why can’t a scanner just use CVE and NVD data directly?
Because NVD describes affected products with CPE, a naming scheme designed for enterprise software inventories rather than package registries. There is no dependable CPE for a specific Maven coordinate or npm package version, so mapping a CVE onto "org.example:lib:1.2.3" involves guesswork that produces both false positives and misses. OSV records instead key on ecosystem, package name and version ranges — exactly the coordinates that appear in a lockfile or POM — so the match is direct.
Does the NVD still score every CVE?
No. On 15 April 2026 NIST announced that the NVD would no longer enrich most CVEs, citing a 263% rise in submissions between 2020 and 2025. Enrichment is now prioritised for vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog, those affecting federal government software, and those in software deemed critical under Executive Order 14028; everything else is listed but flagged "Lowest Priority — not scheduled for immediate enrichment." For a typical open-source library in your lockfile, that means an official NVD severity score may never be assigned — which is a strong practical argument for scanning against ecosystem advisory data that does not depend on that pipeline.
Do all open-source vulnerabilities have a CVE ID?
No. Plenty of ecosystem advisories are published without one — maintainers fix an issue and record it in an ecosystem advisory database, and no CVE is ever requested. Malicious and typosquatted packages are the clearest case: the package is not vulnerable, it is hostile, and the CVE model fits it poorly. A scanner keyed only to CVE IDs is structurally blind to that whole category.
Is an open vulnerability database as trustworthy as a commercial one?
It is a different trade-off rather than a strictly worse one. Commercial databases add curation and their own research, but their findings are not independently auditable and they do not travel with you when you change tools. Open, aggregated data can be inspected record by record, re-queried by any tool, and kept after you switch vendors. For most teams the deciding factor is not raw record count but whether the evidence remains verifiable and portable.
Does a vulnerability database tell me whether I am actually exploitable?
No. Any database, open or commercial, tells you that an affected version is present in your dependency tree. It cannot tell you whether the vulnerable code path is reachable in your application, or whether a compensating control already blocks it. That judgement is yours to make and record — which is what a documented waiver, and VEX for telling downstream consumers, exist to do.
Sources
- NIST — “NIST Updates NVD Operations to Address Record CVE Growth” (15 April 2026) — the enrichment prioritisation change and the submission-growth figures.
- NVD — CPE Dictionary — CPE’s definition and the curated-name model.
- OSV Schema (OpenSSF) and osv.dev — the record format and the aggregating database.
- The CVE Program — CVE IDs and CNA assignment. The April 2025 contract extension is documented here.
Facts about the NVD and the CVE Program are dated because they change. Last checked 14 August 2026 — if you are reading this much later, verify against the primary sources above before relying on it.
Keep reading
- What software composition analysis actually is — where vulnerability data sits in the wider SCA picture.
- Severity is a bad prioritiser — what to do once you have the findings, and why an unenriched CVE must not be treated as a low-severity one.
- Why npm & pnpm audit miss vulnerabilities — the same single-source problem, seen from inside the JavaScript ecosystem.
- Zero findings is not zero risk — why an empty report is ambiguous, and the signatures that tell the two meanings apart.
- End-of-life dependencies — what neither database carries: whether anyone is still shipping fixes.
- VEX and vulnerability waivers explained — the standard way to say “that CVE doesn’t affect us,” and what to do about the findings you can’t fix today.
General information for engineering and security teams, not legal or compliance advice. depproof is not affiliated with the CVE Program, MITRE, NIST, or the OSV project; names are used nominatively.