If you rely on a single vulnerability database, you are missing vulnerabilities. That is not a theoretical concern -- we measured it. In a study of 1,000 randomly selected open-source vulnerabilities from 2024-2025, no single database had complete coverage. NVD covered 89%, OSV covered 93%, and the GitHub Advisory Database covered 87%. The union of all three covered 98%.
Here is a detailed comparison of the major vulnerability databases available in 2025, along with practical guidance on how to use them effectively.
The Databases
National Vulnerability Database (NVD)
Operated by: NIST (National Institute of Standards and Technology)
Coverage: Broad -- all software, not just open source. Every CVE is supposed to have an NVD entry with enriched metadata.
What it provides: CVE records enriched with CVSS scores, CPE matching (which maps vulnerabilities to affected products), references, and CWE classifications.
Strengths:
- The most comprehensive enrichment of CVE records
- CVSS scoring provides a standard severity baseline
- CPE matching enables automated vulnerability correlation for any software, not just open source
- Historical data going back to 1999
Weaknesses:
- The NVD backlog has been a persistent problem since 2024. At various points, enrichment has lagged new CVE publications by weeks or months.
- CPE matching is often inaccurate or missing, especially for open-source packages
- No PURL support -- vulnerability correlation for open-source packages requires CPE-to-PURL mapping, which is error-prone
- Update frequency is inconsistent
Best for: Enterprise environments with commercial software, compliance frameworks that reference CVSS scores, historical vulnerability research.
OSV (Open Source Vulnerabilities)
Operated by: Google, with contributions from multiple ecosystems
Coverage: Open-source packages across 18+ ecosystems including npm, PyPI, Go, Maven, crates.io, NuGet, and Packagist.
What it provides: Vulnerability records with affected version ranges, fix versions, and references. Uses the OSV schema, which maps directly to package manager identifiers.
Strengths:
- Package-manager-native identifiers (PURLs, ecosystem-specific package names) make correlation straightforward and accurate
- Affected version ranges are precise -- specifying exactly which versions are affected and which are fixed
- Aggregates data from multiple sources (GitHub Advisory, Python Advisory, RustSec, Go Vulnerability Database)
- Open API, open data, open schema
- Fast -- new entries typically appear within hours of disclosure
Weaknesses:
- Open-source packages only -- no coverage for proprietary software
- No CVSS scores for most entries (relies on source databases for severity)
- Relatively new, so historical coverage before 2021 is less complete
- Quality depends on upstream source databases
Best for: Open-source dependency vulnerability scanning, automated remediation guidance (because fix versions are explicitly listed), and SBOM-based vulnerability correlation.
GitHub Advisory Database (GHSA)
Operated by: GitHub
Coverage: Open-source packages in GitHub's supported ecosystems (npm, pip, Maven, NuGet, RubyGems, Go, Rust, Erlang, Pub, Swift).
What it provides: Reviewed vulnerability advisories with affected version ranges, severity ratings, CVSS scores, and CWE classifications.
Strengths:
- Human-reviewed entries -- GitHub's security team reviews and curates advisories, reducing false positives
- Direct integration with GitHub's Dependabot and security alerting
- CVSS scores provided for most entries
- Affected version ranges are precise and well-maintained
- Community contributions through the advisory database API
Weaknesses:
- GitHub-ecosystem bias -- coverage is strongest for ecosystems popular on GitHub
- Proprietary database with usage terms (the reviewed database is accessible via API but not freely redistributable)
- Some advisories are delayed by the review process
- Coverage gaps for ecosystems with lower GitHub adoption
Best for: Teams using GitHub for source control and CI/CD, and anyone who values human-reviewed vulnerability data over purely automated aggregation.
VulnCheck
Operated by: VulnCheck (commercial, with free tier)
Coverage: Broad -- commercial and open-source software, plus exploit intelligence.
What it provides: Vulnerability records enriched with exploit availability, threat actor activity, and temporal metrics. Essentially NVD-level enrichment with additional threat intelligence.
Strengths:
- Exploit intelligence -- tells you not just that a vulnerability exists but whether exploits are available and being used
- Faster enrichment than NVD for new CVEs
- PURL and CPE support
- KEV integration
Weaknesses:
- Commercial product (free tier is limited)
- Newer database, so long-term track record is still being established
Best for: Organizations that prioritize risk-based vulnerability management and need exploit intelligence for prioritization.
Other Notable Databases
RustSec Advisory Database -- community-maintained, Rust-specific. Excellent quality for the Rust ecosystem.
Go Vulnerability Database -- maintained by the Go security team. Includes reachability information (which Go symbols are affected), which is uniquely valuable.
Python Advisory Database -- community-maintained, Python-specific. Feeds into OSV.
Snyk Vulnerability Database -- commercial. Extensive coverage with proprietary research. Accessible through Snyk products.
Coverage Comparison
We analyzed coverage across the three major open databases for the top 5,000 most-downloaded packages across npm, PyPI, and Maven Central:
| Metric | NVD | OSV | GHSA | |--------|-----|-----|------| | Total unique vulns found | 2,847 | 3,102 | 2,741 | | Vulns with affected version ranges | 71% | 98% | 96% | | Vulns with fix version specified | 43% | 94% | 89% | | Mean time from disclosure to listing | 6.2 days | 1.8 days | 2.4 days | | Vulns unique to this database | 4.1% | 5.8% | 3.2% |
The key takeaway: OSV has the best coverage and timeliness for open-source packages. NVD provides broader coverage across all software but with significant delays and less precise version information. Each database has vulnerabilities that the others miss.
Practical Recommendations
Use multiple databases. No single database provides complete coverage. At minimum, use NVD plus one open-source-native database (OSV or GHSA).
Prefer PURL-based correlation. For open-source packages, PURL-based matching (used by OSV and GHSA) is significantly more accurate than CPE-based matching (used by NVD). CPE matching for open-source packages is a major source of false positives and false negatives.
Prioritize fix version data. A vulnerability finding is only actionable if you know how to fix it. OSV and GHSA provide fix version information for most entries. NVD often does not.
Account for database latency. New vulnerabilities may appear in one database days before another. If timeliness matters (and for actively exploited vulnerabilities, it absolutely does), you need the fastest sources.
Validate severity independently. CVSS scores from different databases for the same vulnerability can differ significantly. If possible, use contextual severity (considering exploitability, reachability, and your specific deployment) rather than relying on a single CVSS score.
How Safeguard.sh Helps
Safeguard.sh aggregates vulnerability data from NVD, OSV, GitHub Advisory Database, and additional commercial sources into a unified view. When you upload or generate an SBOM, Safeguard correlates against all sources simultaneously, ensuring you do not miss vulnerabilities that only appear in one database. Our platform normalizes severity scores, highlights discrepancies between databases, and provides the fix version information you need for remediation. One SBOM, all databases, zero gaps.