Question 1

What Is NVD?

Accepted Answer

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:lodashproject: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.

Question 2

What Is OSV?

Accepted Answer

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.