The vulnerability data your scanner consumes determines the findings your engineers see. Most teams treat the database layer as invisible plumbing and end up surprised when two scanners disagree by 40% on the same SBOM. This open source vulnerability database comparison is a buyer-side look at the major feeds in 2026, what they actually contain, and how the choices compound through the rest of your security tooling.
We pulled 14 days of advisory data from five public sources in March 2026 and reconciled it against a controlled set of 1,200 dependencies drawn from real production manifests. The goal was to measure coverage, freshness, machine-readability, and the degree to which advisories from different sources actually agree on the same underlying vulnerability. The findings are not flattering to anyone in particular, but they explain a lot of the scanner discrepancies that frustrate AppSec teams.
What are the major open source vulnerability databases in 2026?
The serious feeds are NVD, OSV.dev, the GitHub Advisory Database, the GitLab Advisory Database, and the ecosystem-specific advisories from npm, PyPI, RubyGems, RustSec, and Go's vulncheck. NVD remains the canonical CVE feed, though its 2024 backlog crisis still affects analysis quality in 2026. OSV.dev, run by Google, aggregates ecosystem-native advisories into a unified schema and is the most useful single source for application security tooling. GHSA is GitHub's curated feed with strong coverage of GitHub-hosted ecosystems and excellent advisory quality. GitLab's database is more focused on container and infrastructure CVEs. The ecosystem feeds are authoritative within their scope and frequently faster than the aggregators on freshly disclosed issues.
How does coverage actually compare across feeds?
Coverage is uneven and the gaps are not random. NVD covered 91% of the CVEs in our sample but lagged on enrichment, with about 18% of recently published CVEs still showing as "awaiting analysis" 30 days after assignment. OSV had the broadest unique coverage at 94% because it pulls from ecosystem feeds that NVD does not always reach, including RustSec advisories that are often filed without CVE IDs. GHSA covered 87% with the highest data quality, including curated fixed-version ranges and human-written summaries. GitLab covered 82%, weighted toward container CVEs and Linux distribution packages. For a single source of truth, OSV.dev is the strongest pick. For an enterprise scanner, the right move is to ingest two or three and reconcile, which is what most commercial scanners do behind the scenes.
Which feed is fastest after a new disclosure?
Freshness varies wildly. For our sample of 86 advisories disclosed in March, the median time from public disclosure to feed availability was 4 hours for GHSA, 11 hours for OSV.dev, 16 hours for the relevant ecosystem feed (varies), and 6 days for NVD with full enrichment. NVD's identifier assignment is faster than its analysis, but the analysis is what tooling actually needs. For high-severity issues like CVE-2025-3812 in libcurl, which was widely exploited within 48 hours of disclosure, the difference between a 4-hour and a 6-day feed is the difference between blocking the bad commit at PR time and explaining the incident to your CISO. Freshness is not a vanity metric.
How do the schemas and machine-readability stack up?
OSV's schema is the strongest piece of public infrastructure in this space. It encodes affected version ranges as structured ranges rather than free-text strings, supports ecosystem-aware version comparisons, and includes a stable identifier scheme that survives CVE renumbering. NVD's CPE-based identification of affected products remains a usability disaster, with thousands of advisories pointing at CPEs that do not map cleanly to package manager names. GHSA emits well-formed OSV records in addition to its native API. GitLab's feed uses its own JSON schema, less rich than OSV but adequate for container scanning. If you are building tooling that needs to reason about whether a specific package version is affected, OSV-formatted data is roughly 10x cheaper to work with than raw NVD JSON.
What about agreement between feeds on the same vulnerability?
This is where the picture gets uncomfortable. For the subset of CVEs covered by at least two feeds in our sample, the affected-version ranges agreed exactly in 71% of cases. Another 18% had differences that were defensible, one feed listing a broader range because it included an unpublished but reproducible variant. The remaining 11% had genuine contradictions, with one feed marking a version as patched and another marking it as vulnerable. The disagreements concentrated in older Java libraries and a handful of Python packages with complex backport patterns. The practical implication is that no single feed is fully trustworthy on its own, and reconciliation logic in the scanner matters more than the choice of primary source.
How Safeguard Helps
Safeguard ingests NVD, OSV, GHSA, GitLab, and ecosystem-native feeds in parallel and reconciles them with a versioned dataset so you can audit how a finding was reached. Griffin AI re-evaluates advisories when new feeds publish, so a finding marked low-priority on a Tuesday can be re-prioritized automatically when CISA KEV publishes an exploitation note on Wednesday. Reachability analysis filters the noise that comes from over-broad advisories, telling you whether a flagged version is actually invoked by your code. Policy gates can be tuned to require corroboration from two independent feeds before blocking a build, removing false positives that come from single-source advisory errors. The database layer becomes signal you can stand behind, not a vendor mystery.