Vulnerability databases

Vulnerability databases are registries that catalogue known security vulnerabilities in software, firmware, and cloud configurations. Each entry typically identifies an affected component, describes the weakness, and records a stable identifier so that tools and teams can refer to it unambiguously. They are a core input to security testing and to the broader software assurance activities that give justified confidence a system is free of exploitable flaws.

Most databases trace back to a single common identifier scheme: the CVE record. The CVE Program, operated by the MITRE Corporation and sponsored by the US Cybersecurity and Infrastructure Security Agency (CISA), assigns a globally unique CVE ID (of the form CVE-YYYY-NNNNN) to each publicly disclosed vulnerability. The records themselves are brief — an identifier, a description, and references — and are contributed by a federation of CVE Numbering Authorities (CNAs): vendors, research organizations, and OWASP-style communities authorized to assign IDs in their domain. CVE is a dictionary, not a scoring system. It answers "which vulnerability?" but not "how bad is it?".

Enrichment layers sit on top of the CVE identifiers. The National Vulnerability Database (NVD), run by NIST, is the most widely used. It ingests CVE records and adds a severity score under the Common Vulnerability Scoring System (CVSS), an affected-product listing in Common Platform Enumeration (CPE) form, and curated references. The NVD is the reference repository for standards-based vulnerability management in the US government and beyond. Other databases aggregate CVE and ecosystem-specific advisories and add fix paths, package mapping, and query APIs. OSV: Open Source Vulnerabilities, which Google seeded, federates advisories from dozens of upstream sources (PyPA, RustSec, GitHub, and others) so that a single query covers many open-source ecosystems. The Snyk Vulnerability Database and the GitHub Advisory Database are commercial and community efforts oriented toward open-source dependencies and remediation guidance.

The practical consumer of these databases is software composition analysis (SCA), a class of tool that compares a project’s declared dependencies — often compiled into a software bill of materials (SBOM) — against the database and reports any matches. SCA is the dependency-scanning counterpart to the source-level static analysis family, and both are standard shift left controls in a secure by design lifecycle. The output feeds penetration testing triage, where a known CVE in a dependency may be a faster route to demonstration than a novel exploit.

Important

A database hit is a lead, not a verdict. Coverage is uneven across ecosystems, and a CVE may be disputed, retracted, or superseded. Two databases can disagree on whether a given package version is affected, because the mapping from a human-language advisory to exact package coordinates is itself an interpretation. Treat matches as candidates for review, not as automatic verdicts.

Notable databases

See also