OSV vs NVD: Comparing Vulnerability Databases for Dependency Security

You run your scanner against a Node.js project. Zero vulnerabilities. Clean bill of health.

Then you switch to a different scanner backed by a different database. Three advisories appear — one critical. The advisories existed in GitHub's Security Advisory Database for weeks, but NVD hadn't ingested them yet. Your first scanner only checked NVD.

This isn't a hypothetical. Since mid-2024, NVD has struggled with a persistent backlog of unanalyzed CVEs. Processing delays of 30 days or more became routine. Some CVEs sat for months without CVSS enrichment. The database that the security industry treated as canonical started falling behind the threat landscape it was supposed to track.

The gap exposed a reality that many teams hadn't confronted: no single vulnerability database covers everything. The database you choose determines what your scanner can find — and what it silently misses.

What We'll Cover

• The problem: no single database is complete
• What is NVD?
• What is OSV?
• Side-by-side comparison
• Why GeekWala uses both
• Other vulnerability databases worth knowing
• What this means for developers
• FAQ

The Problem: No Single Database Is Complete

Vulnerability databases differ in three fundamental ways: what they cover, how fast they update, and how they identify affected software.

Coverage gaps are the norm, not the exception. NVD aims to catalog every publicly disclosed vulnerability across all software — operating systems, firmware, commercial applications, and open-source libraries. OSV focuses exclusively on open-source packages but aggregates advisories from over a dozen ecosystem-specific databases. A vulnerability in a Go module might appear in Go's vulnerability database within hours, show up in OSV the same day, and take NVD three weeks to process.

Speed matters more than most teams realize. The window between public disclosure and active exploitation has been shrinking. FIRST.org's EPSS data shows that vulnerabilities with publicly available exploit code are often weaponized within days. A scanner that relies on a database with a 30-day processing lag is, functionally, blind during the highest-risk period.

Identification accuracy varies dramatically. NVD uses CPE (Common Platform Enumeration) strings to identify affected software. CPE was designed for operating systems and commercial products, not package managers. Mapping lodash@4.17.20 to a CPE string is error-prone — and NVD's CPE matching has a well-documented history of false positives and false negatives. OSV uses PURL (Package URL), which maps directly to ecosystem-native identifiers: pkg:npm/lodash@4.17.20. No ambiguity.

The result: teams that rely on a single database accept blind spots they may not even know exist.

What Is NVD?

The National Vulnerability Database is maintained by NIST (National Institute of Standards and Technology), a U.S. government agency. It has been the de facto standard for vulnerability data since its launch in 2005.

How it works: When a vulnerability is assigned a CVE identifier by a CVE Numbering Authority (CNA), it enters the NVD pipeline for analysis. NIST analysts review the vulnerability, assign CVSS severity scores, map it to affected products using CPE strings, and publish the enriched record.

What NVD does well:

• Broad coverage. NVD covers all software categories — not just open-source. If a vulnerability affects a commercial firewall, a Linux kernel module, or a Windows driver, NVD tracks it.
• Authoritative CVSS scores. NIST assigns CVSS base scores using a consistent methodology. These scores are widely referenced in compliance frameworks (PCI DSS, FedRAMP, SOC 2) and risk management processes.
• Historical depth. NVD's archive stretches back decades. For legacy systems running older software, NVD is often the only source with vulnerability data.
• Well-established ecosystem. Thousands of tools, dashboards, and compliance systems integrate with NVD feeds. Its CVE JSON 5.0 format is broadly supported.

Where NVD struggles:

• Processing delays. NIST acknowledged a significant backlog in early 2024. As of early 2026, newly submitted CVEs routinely wait 30 or more days before receiving full NVD analysis. Some languish for months.
• CPE mapping errors. CPE strings were not designed for the granularity that package-level vulnerability matching requires. A CPE like cpe:2.3:a:lodash_project:lodash:4.17.20:*:*:*:*:node.js:*:* is fragile — vendor name changes, package renames, and scoping ambiguities produce both false positives (flagging unaffected versions) and false negatives (missing affected versions).
• No ecosystem-native identifiers. NVD doesn't speak npm, PyPI, or crates.io natively. Tools that consume NVD data must build their own mapping layer between CPE strings and package manager identifiers — and every mapping layer introduces errors.
• Enrichment gaps. Even when a CVE appears in NVD, it may lack a CVSS score for weeks or months if the analysis backlog is large. A CVE record without a severity score is significantly less useful for triage.

What Is OSV?

OSV (Open Source Vulnerabilities) is a distributed vulnerability database launched by Google's Open Source Security team in 2021. Rather than maintaining its own advisory review process, OSV aggregates advisories from ecosystem-specific databases and normalizes them into a consistent schema.

How it works: OSV pulls advisories from authoritative sources — GitHub Security Advisories (GHSA), PyPA Advisory Database, RustSec, Go Vulnerability Database, and others. Each advisory is normalized into the OSV Schema, an open specification that uses PURL identifiers and semantic version ranges to describe affected packages.

What OSV does well:

• Near real-time updates. When a maintainer publishes a GitHub Security Advisory, it appears in OSV within hours — sometimes minutes. There is no manual analysis bottleneck.
• Ecosystem-native identifiers. OSV uses PURL (Package URL), which maps directly to package manager coordinates. pkg:npm/express@4.17.1 is unambiguous. No CPE translation layer needed.
• Precise version ranges. OSV advisories specify affected version ranges using the ecosystem's native versioning scheme (semver for npm, PEP 440 for PyPI, etc.). This eliminates the version-matching ambiguity that plagues CPE-based approaches.
• Open source and open data. The OSV Schema is an OSSF (Open Source Security Foundation) standard. The database and API are freely available under CC BY 4.0.
• API-first design. OSV's REST API supports batch queries — submit a list of packages and versions, get back all matching advisories in one call. This makes integration straightforward.

Where OSV falls short:

• No independent CVSS scoring. OSV passes through whatever severity information the upstream source provides. If a GHSA advisory includes a CVSS score, OSV includes it. If it doesn't, OSV has no score to offer. There is no independent severity analysis.
• Open-source packages only. OSV does not cover commercial software, operating systems (at the distro level), firmware, or hardware. If your attack surface includes proprietary components, OSV won't help.
• Newer, less legacy coverage. OSV's historical depth depends on its upstream sources. For vulnerabilities disclosed before 2019 in smaller ecosystems, coverage can be sparse.
• Upstream quality varies. OSV is only as good as its sources. Most ecosystem databases (GHSA, RustSec) are well-maintained, but quality and completeness vary.

Side-by-Side Comparison

The short version: NVD is broad but slow. OSV is fast but narrow. For open-source dependency scanning, OSV's speed and precision usually matter more — but NVD's CVSS scores and compliance recognition remain essential.

Why GeekWala Uses Both

GeekWala's scanning pipeline queries multiple vulnerability data sources because each one fills gaps the others leave:

OSV for speed and ecosystem-native matching. When you upload a package.json, requirements.txt, go.mod, or Cargo.lock, GeekWala resolves your dependency tree and queries OSV using PURL identifiers. Because OSV uses ecosystem-native package coordinates and semantic version ranges, matches are precise — no CPE translation errors, no false positives from ambiguous vendor strings.

NVD for CVSS enrichment. When OSV returns an advisory that references a CVE but lacks a CVSS score, GeekWala cross-references NVD for the authoritative severity rating. This ensures every finding in your scan results includes a severity score for triage, even when the upstream ecosystem database didn't provide one.

EPSS for exploitation probability. Raw severity scores don't tell you which vulnerabilities are actively being targeted. GeekWala enriches every CVE with EPSS scores from FIRST.org, giving you a data-driven estimate of whether a vulnerability will be exploited in the next 30 days. A CVSS 9.8 with an EPSS of 0.02 is less urgent than a CVSS 7.0 with an EPSS of 0.85.

CISA KEV for confirmed exploitation. The CISA Known Exploited Vulnerabilities catalog lists CVEs with confirmed real-world exploitation. GeekWala flags any dependency vulnerability that appears on the KEV list, so confirmed threats surface immediately — regardless of their CVSS or EPSS scores.

The multi-source advantage. In practice, querying both OSV and NVD (plus EPSS and KEV enrichment) catches roughly 20% more actionable advisories than relying on either database alone. The gap comes from three sources: advisories that exist in ecosystem databases but haven't reached NVD yet, advisories with NVD records but no corresponding OSV entry (common for older or cross-ecosystem vulnerabilities), and enrichment data (CVSS, EPSS, KEV) that only exists in one source. The first of those three is smaller than it sounds — we measured the NVD-to-registry gap directly across 48,162 CVEs and found a median of 0.01 days, so "hasn't reached NVD yet" is rarely a multi-day wait in practice.

┌─────────────────────────────────────────────────────┐
│                GeekWala Scan Pipeline                │
│                                                      │
│  ┌──────────┐   ┌──────────┐   ┌──────────────────┐ │
│  │ Your     │   │ Resolve  │   │ Query OSV        │ │
│  │ manifest │──▶│ dep tree │──▶│ (PURL matching)  │ │
│  │ file     │   │          │   │                  │ │
│  └──────────┘   └──────────┘   └────────┬─────────┘ │
│                                         │            │
│                                         ▼            │
│                              ┌──────────────────┐    │
│                              │ Enrich with:     │    │
│                              │ • NVD CVSS       │    │
│                              │ • EPSS scores    │    │
│                              │ • CISA KEV flags │    │
│                              └────────┬─────────┘    │
│                                       │              │
│                                       ▼              │
│                              ┌──────────────────┐    │
│                              │ Prioritized      │    │
│                              │ results with     │    │
│                              │ severity + risk  │    │
│                              └──────────────────┘    │
└─────────────────────────────────────────────────────┘

This layered approach means you get the fastest possible detection (OSV), the most recognized severity scores (NVD CVSS), exploitation probability (EPSS), and confirmed threat intelligence (CISA KEV) — all in a single scan.

Other Vulnerability Databases Worth Knowing

OSV and NVD are not the only players. Several other databases serve important roles in the vulnerability intelligence ecosystem:

GitHub Security Advisories (GHSA). GitHub maintains its own advisory database, curated by GitHub's security team and the open-source community. GHSA advisories are reviewed, often include remediation guidance, and map directly to GitHub's Dependabot alerts. GHSA is one of OSV's primary upstream sources.

RustSec Advisory Database. The Rust ecosystem maintains RustSec, a community-driven advisory database for Rust crates. Advisories are filed as structured TOML documents in a public Git repository. RustSec feeds into OSV and powers cargo audit.

PyPA Advisory Database. Python's Packaging Authority maintains an advisory database focused on PyPI packages. It feeds into OSV and is used by pip-audit.

Go Vulnerability Database. The Go team at Google maintains vuln.go.dev, which tracks vulnerabilities in Go modules. It powers govulncheck and feeds into OSV. Go's database is notable for mapping vulnerabilities to specific affected functions, not just packages.

Commercial databases. Snyk, VulnDB (Risk Based Security), and Sonatype maintain proprietary vulnerability databases with their own research teams. These often include vulnerabilities not yet assigned CVE identifiers, as well as malicious package detections. The trade-off is cost and vendor lock-in. For a broader comparison of scanning tools, see our dependency scanners compared guide.

The ecosystem-specific databases (GHSA, RustSec, PyPA, Go Vulndb) are generally the first to publish advisories for their respective ecosystems. OSV aggregates them. NVD eventually indexes them. This layering means that the closer your scanner is to the ecosystem source, the faster it detects new issues.

What This Means for Developers

If you take away one thing from this comparison: don't rely on a single vulnerability data source.

The practical implications:

Check what your scanner queries. Most scanners document their data sources. If yours only queries NVD, you're accepting a 30+ day detection lag for many open-source vulnerabilities. If it only queries one ecosystem database, you're missing cross-ecosystem coverage.

Prioritize with multiple signals. A vulnerability's CVSS score tells you how severe it could be. Its EPSS score tells you how likely it is to be exploited. Its CISA KEV status tells you if it's already being exploited. Using all three together produces better triage decisions than any single metric. For a deeper dive into prioritization frameworks, see our vulnerability prioritization guide.

Automate, don't audit manually. Manually checking NVD and OSV for every dependency in your project doesn't scale. Even a small Node.js application has hundreds of transitive dependencies. Automated scanning that queries multiple sources and surfaces prioritized results is the only practical approach.

Understand your compliance requirements. Some compliance frameworks (PCI DSS, FedRAMP, SOC 2) specifically reference NVD and CVSS scores. If your organization operates under these frameworks, you need NVD data regardless of OSV's advantages. A scanner that provides both gives you security coverage and compliance documentation from the same workflow.

FAQ

Which vulnerability database is more accurate?

It depends on what you're scanning. For open-source packages in major ecosystems (npm, PyPI, Maven, Go, Rust, RubyGems, NuGet, Packagist), OSV is typically more accurate because it uses ecosystem-native identifiers (PURL) and semantic version ranges. NVD's CPE-based matching introduces false positives and false negatives, particularly for packages where the vendor name is ambiguous or the package has been renamed. For non-open-source software (commercial applications, operating systems, firmware), NVD is the only option with meaningful coverage.

Does OSV replace NVD?

No. OSV and NVD serve different purposes and cover different scopes. OSV focuses on open-source packages with ecosystem-native precision. NVD covers all software categories and provides authoritative CVSS scores used in compliance frameworks. For open-source dependency scanning, OSV is the better primary source — but NVD remains essential for CVSS enrichment, historical coverage, and compliance requirements. The best approach is to use both.

How often are vulnerability databases updated?

OSV updates continuously as its upstream sources (GHSA, RustSec, PyPA, Go Vulndb) publish new advisories — typically within hours of disclosure. NVD updates are slower: new CVEs enter the database when assigned by a CNA, but full analysis (CVSS scoring, CPE mapping) has been delayed by 30 or more days since NIST's processing backlog emerged in 2024. EPSS scores update daily. The CISA KEV catalog updates as new confirmed exploitations are identified, typically within days of confirmation.

---

Scan your dependencies against both OSV and NVD — with EPSS and CISA KEV enrichment — in a single scan. Try GeekWala free and see what a multi-source approach catches that single-database scanners miss.