Systems Software Data: Package Registries, Vulnerability Records and Fleet Telemetry · Head-to-head
NVD CVE & CPE Data Feeds and APIs vs OSV - Open Source Vulnerability Database
Which systems software data: package registries, vulnerability records and fleet telemetry data fits your job: NVD CVE & CPE Data Feeds and APIs, or OSV - Open Source Vulnerability Database. API, files, or your warehouse. Daily, weekly, or hourly.
NVD CVE & CPE Data Feeds and APIs
OSV - Open Source Vulnerability Database
Where the fields line up
2 shared fields — join on these.
| Field | NVD CVE & CPE Data Feeds and APIs | OSV - Open Source Vulnerability Database |
|---|---|---|
id | CVE identifier of the record inside vulnerabilities[].cve; the primary key every downstream table joins on. | Required identifier in <DB>-<ENTRYID> form; the stable key every delivery joins on. |
published | ISO 8601 timestamp when the CVE was published. | RFC3339 UTC publication timestamp of the original disclosure. |
What each contains
Pick by fit, not by loyalty.
| NVD CVE & CPE Data Feeds and APIs | OSV - Open Source Vulnerability Database | |
|---|---|---|
| Primary identifier | `id` - the CVE identifier (`CVE-2019-10906`) | `id` - database-prefixed form (`GHSA-462w-v97r-4m45`) |
| Publication timestamp | `published` - ISO 8601 (sample: 2019-04-07T00:29:00.213) | `published` - RFC3339 UTC (same flaw: 2019-04-10T14:30:24Z) |
| Revision tracking | `lastModified` beside a `vulnStatus` lifecycle enum (Modified, Awaiting Analysis, Analyzed, Rejected) | Required `modified` timestamp; latest wins when aggregating conflicting entries |
| Severity scoring | `metrics.cvssMetricV31` vectors and base scores, with V2 metrics retained | `severity` objects typed CVSS_V2, CVSS_V3, CVSS_V4 or Ubuntu, each tagged to a source |
| What is affected | `configurations` - OR/AND applicability trees whose leaf `cpeMatch` entries carry criteria strings for product versions | `affected[].ranges` - SEMVER, ECOSYSTEM or GIT ranges with introduced/fixed/last_affected/limit events |
| Explicit version lists | Implied inside criteria strings rather than enumerated | `affected[].versions` - explicit affected version strings, recommended whenever available |
| Weakness taxonomy | `weaknesses` - first-class CWE mappings (one on the sample record) | CWE ids supplied in `database_specific` (`CWE-693` on the sample advisory) |
| Narrative text | `descriptions` - language-tagged objects, English plus Spanish | `summary` one-liner (about 120 characters) plus `details` in CommonMark |
| Provenance | `sourceIdentifier` - the assigning organization | Typed `references` (ADVISORY, FIX, REPORT and kin) plus credits |
| Extension room | None documented beyond the nine columns | — |
| Overlap verdict | Spine only: identity, timestamps, CVSS and CWE. Product-tree scoping lives exclusively on the NVD side. | — |
Where they're equivalent
More than the product-versus-package framing implies.
- Both key on one identifier per flaw - a CVE id on one side, a database-prefixed id on the other - and both resolve unambiguously to a single real-world vulnerability.
- Both double-stamp time: publication and last modification travel separately on each side, so disclosure date is always separable from latest revision.
- Both carry CVSS vectors - as
metrics.cvssMetricV31objects on the NVD side, as typedseverityentries (CVSS_V2/V3/V4 or Ubuntu) on the OSV side. - Both trace coding faults to CWE: a first-class
weaknessesfield on one side, source-supplied CWE ids indatabase_specificon the other. - Both are global and deliberately non-geographic - one keyed to products, the other to ecosystems.
- Both ship fully verified field dictionaries, definitions checked during live research on August 21, 2026 - a standard met by roughly 86 percent of the catalog.
- Both score 10 out of 10, tied at the top of a rubric where just 145 of 1,744 datasets reach that mark.
Neither substitutes for the other: NVD carries no package-range algebra, OSV carries no CPE product trees.
The verdict
Verdict: sample both - the shape of your asset base decides, and most security programs hold both shapes.
Take NVD CVE & CPE Data Feeds and APIs when the estate is infrastructure and commercial software: joining disclosed flaws against your inventory through CPE criteria strings, ranking patch queues by CVSS base score among only the product versions you run, monitoring vendor risk as flaw accumulation per product family, or training severity models on twenty-four years of scored, weakness-mapped records.
Take OSV - Open Source Vulnerability Database when the estate is code: screening a bill of materials package by package, deciding whether a pinned version falls inside an introduced-to-fixed window, planning upgrades off fixed events, counting ecosystem-wide exposure, or resolving every finding to its CVE id for audit evidence.
Developers and builders and data scientists earn their keep on both sides - the first pair wire screening into pipelines, the second find labeled corpora in either direction. Competitive-intel teams tend to start with NVD for vendor-quality signals and OSV for dependency diligence.
Sample both, pick by fit. See NVD CVE & CPE Data Feeds and APIs · See OSV - Open Source Vulnerability Database
Fair questions
Is NVD CVE & CPE Data Feeds and APIs better than OSV - Open Source Vulnerability Database for vulnerability analytics?
Different instruments, tied on craft - both score 10 out of 10. NVD wins whenever the question concerns products: roughly 381,000 scored CVE records with CPE applicability statements matching flaws to operating-system, database, hypervisor and middleware versions. OSV wins whenever it concerns packages: 848,582 advisories across 38 ecosystems with ranges that bracket the vulnerable window down to versions and commits.
Do NVD and OSV cover the same vulnerabilities?
They overlap where open-source flaws earn CVE identifiers, and the overlap is joinable rather than incidental. The Jinja sandbox escape is CVE-2019-10906 in NVD and GHSA-462w-v97r-4m45 in OSV, whose aliases field states the equivalence outright. Flaws disclosed only through vendor channels stay NVD-only; advisories without a CVE alias stay OSV-only.
Which dataset tells you whether your specific version is affected?
Both, over different estates. NVD's configurations tree answers it for products - a criteria string matches your build or it does not. OSV's affected[].ranges answer it for packages, with SEMVER, ECOSYSTEM and GIT windows plus explicit version lists, and the fixed event naming the release that closes each hole.
Can you track a CVE identifier into an OSV record?
Yes - aliases make it an equality test, not a search. The field carries the same vulnerability's identifiers in other databases, symmetrically and transitively, so CVE-2019-10906 resolves to GHSA-462w-v97r-4m45 and PYSEC-2019-217 in one record. Mind that not every advisory carries an alias yet, so expect some unmatched rows.
How current can delivered copies of each dataset be?
As current as your project needs: Datadory delivers either daily, weekly, or hourly - your call. Content-wise both are living ledgers: the NVD sample record was published in April 2019 and still showed a Modified status in June 2026, while OSV stamps every correction with a fresh modified timestamp rather than overwriting history.
Can Datadory deliver NVD CVE & CPE Data Feeds and APIs and OSV - Open Source Vulnerability Database together?
Yes - sample both and pick by fit, or take both in one feed. Each arrives normalized to its documented dictionary (nine fields on the NVD side, twelve on the OSV side) with sample rows attached for validation, merged on the CVE identifier where aliases permit, and delivered daily, weekly, or hourly beside the rest of the systems-software catalog.