When we were building the advisory ingestion layer for Patchlynx, we had to make a concrete choice: which data source do you trust when OSV and NVD disagree? And they do disagree — on affected version ranges, on CVSS scores, and sometimes on whether a particular package version is vulnerable at all. This post is our working understanding of the two feeds, where each one is authoritative, and why we ended up pulling from both.
The Structural Difference
The National Vulnerability Database (NVD) is maintained by NIST and has been the canonical source for CVE metadata since 1999. The NVD enriches CVE entries published by MITRE with CVSS scores, CWE classifications, CPE configuration data (which software versions are affected), and references. It's the source that most enterprise SCA tools and compliance frameworks point to when they say "we use industry-standard vulnerability data."
The Open Source Vulnerability database (OSV) is a Google-originated project launched in 2021 with a different design goal: ecosystem-native vulnerability tracking for open source package registries. Where NVD uses CPE (Common Platform Enumeration) to describe affected software — a naming scheme originally designed for commercial products, not npm packages — OSV uses package-and-version tuples native to each ecosystem. An OSV entry for a Go vulnerability says GOMODULE/github.com/foo/bar < 1.2.3. An NVD CPE entry for the same vulnerability says something like cpe:2.3:a:foo:bar:*:*:*:*:*:*:*:* and requires parsing logic to map back to actual Go module versions.
This structural difference has real consequences for how accurately your SCA tool can match advisories to your actual dependency versions.
Update Cadence Matters More Than People Think
The NVD's enrichment pipeline has historically had significant lag. A CVE can be published by MITRE and sit in "AWAITING ANALYSIS" status at NVD for days or weeks before NVD analysts add CVSS scores and CPE configurations. During that window, the CVE has an ID and a description but no machine-readable version data — your SCA tool can't match it to your dependencies because the affected version range hasn't been encoded yet.
In 2023 and early 2024, NVD's analysis backlog became public knowledge within the security community — NIST acknowledged delays in a published notice. For SCA tools that rely exclusively on NVD, this created real coverage gaps: new vulnerabilities weren't appearing in scan results until NVD analysis completed.
OSV's model is different. Advisories can be contributed directly by ecosystem maintainers, package registries (npm, PyPI, crates.io, RubyGems all contribute directly), security researchers, and automated processes. An advisory published to the GitHub Advisory Database feeds into OSV automatically, often within hours of the underlying fix being merged. The affected version range is encoded by someone who knows the package — often the maintainer themselves — rather than a generalist analyst working through a backlog.
For the npm and PyPI ecosystems in particular, OSV's coverage and cadence are meaningfully faster than NVD's for new advisories.
Where NVD Is Still Authoritative
NVD isn't going away and it's not wrong — it's differently authoritative. For CVEs against commercial software, legacy packages, and C/C++ projects without a package registry presence, NVD's CPE data is often the only machine-readable source. OSV's coverage skews heavily toward modern package ecosystems; if you're scanning a Java monorepo that pulls in open source Maven artifacts, OSV covers those, but if you're scanning a C++ codebase that statically links against vendored libraries, NVD CPE is probably your better source.
NVD's CVSS scores also tend to be more consistently computed because they go through a standardized review process. OSV advisory entries sometimes have CVSS scores contributed by the ecosystem database of origin (GHSA in particular does CVSS analysis), and sometimes don't — or have scores that differ from NVD's assessment of the same CVE. Neither is necessarily wrong; a CVSS score is an editorial judgment and reasonable analysts can score the same vulnerability differently on sub-metrics like Attack Complexity or Scope.
The Version Range Accuracy Problem
This is the issue that has the most operational impact on your false positive rate. When an advisory says "affected version range: >= 1.0.0, < 1.4.2", your SCA tool needs to correctly determine whether your installed version falls in that range. This sounds trivial but it's not, and the problem manifests differently in NVD vs OSV.
NVD CPE configurations use a version matching syntax that was designed for commercial software versioning, not npm's semver range semantics. Complex cases — packages that backport fixes, non-linear version numbering, pre-release versions — can result in CPE configurations that either over-include (flagging safe versions) or under-include (missing vulnerable versions) compared to what the actual fix commit boundary is.
OSV's ecosystem-native format handles semver ranges directly and often reflects the exact git commit or tag that introduced the fix. When a maintainer contributes an OSV advisory saying "fixed in 2.1.0-rc.3", that's the actual release boundary, not an approximation made by someone reading the CHANGELOG two weeks later.
In our testing across npm advisories, OSV version ranges are more precisely calibrated to actual fix boundaries than NVD CPE ranges for the same CVEs. This matters for your false positive rate: if NVD's range is slightly too broad, you flag versions that are actually safe. If it's slightly too narrow, you miss vulnerable versions.
How Patchlynx Uses Both
We ingest both feeds and use a merge strategy with clear precedence rules:
- For version range data in npm, PyPI, Go, and Maven ecosystems: OSV is primary. Its ranges are ecosystem-native and typically more precise.
- For CVSS scoring when OSV doesn't include a score or the score differs significantly from NVD: we surface NVD's score with a label indicating source.
- For CVEs against packages not covered by OSV: NVD CPE data is used with parsing logic that maps CPE versions to semver where possible.
- For update freshness: we pull OSV on a 4-hour cadence and NVD on a 12-hour cadence, reflecting the actual update frequency of each source.
We're not saying this is the only reasonable approach. Some teams correctly choose to be NVD-only for compliance reasons — certain frameworks and audit requirements reference NVD by name. If your organization's security policy requires NVD-sourced CVSS scores for risk ratings, that's a valid constraint. The tradeoff is accepting some additional lag and some version range imprecision for newer advisories.
What we'd push back on is the assumption that "NVD-only = more rigorous." For modern open source supply chain security in npm or Python ecosystems, OSV's data quality and freshness are genuinely better for the operational purpose of knowing whether your current lockfile is vulnerable. NVD is authoritative for the CVE ID — that comes from MITRE and NVD's analysis. OSV is often more authoritative for "does version X.Y.Z contain the fix?"
How to Check What Your Current Tool Uses
Most SCA tools list their data sources somewhere in their documentation or FAQ. Look for: which advisory databases are ingested, what the update cadence is, and whether they perform any version range normalization. Key questions to ask:
- What's the lag between a CVE being published and it appearing in my scan results? (Tests this with a recent, well-publicized CVE and check when it showed up.)
- Do you use OSV or GitHub Advisory Database for npm/PyPI advisories, or only NVD?
- When OSV and NVD disagree on an affected version range, which takes precedence?
If the tool you're evaluating can't answer those questions clearly, that's informative. The advisory data layer is the foundation your triage decisions are built on. Understanding its provenance isn't academic — it directly affects which CVEs you act on and which you miss.