A vulnerability database is a structured, searchable catalog of publicly known software security flaws, each assigned a unique identifier, a technical description, affected products and versions, and a severity score. Most practitioners just call it a CVE vulnerability database, since CVE identifiers are the common key every other feed maps back to. The best-known example is the CVE List, which has assigned over 240,000 identifiers since MITRE launched the program in 1999 — including CVE-2021-44228, the Log4Shell flaw disclosed on December 9, 2021, and scored a maximum 10.0 on CVSS 3.1. Vulnerability databases are the raw material behind every scanner, SBOM tool, and patch-prioritization workflow: when a scanner flags a dependency, it is almost always matching a package version against an entry pulled from the National Vulnerability Database (NVD), OSV.dev, or a vendor-specific feed. In 2024, more than 40,000 new CVEs were published — a record, and roughly 38% more than the 28,961 published in 2023 — which is why understanding how these databases are built, enriched, and sometimes delayed matters directly to how fast your team can respond to real risk.
How does a vulnerability actually get into a database?
A vulnerability enters a database when a CVE Numbering Authority (CNA) assigns it an identifier, then a separate analysis stage enriches it with severity and affected-product data. The process starts with discovery — by a researcher, vendor, or automated fuzzing tool — followed by responsible disclosure to a CNA, of which there were more than 370 authorized organizations by the end of 2024, including major vendors like Microsoft, Red Hat, and GitHub, who can each assign CVE IDs directly to flaws in their own products. MITRE issues the base CVE record (ID, description, references) as the system of record, but that record initially ships with minimal metadata. NVD, run by NIST, then performs a second enrichment pass, adding a CVSS score, CWE weakness classification, and CPE affected-configuration strings. This two-stage pipeline — assignment, then enrichment — is why the same CVE can sit in MITRE's list for days or weeks with "awaiting analysis" status before it carries a usable severity score.
What's the difference between the CVE List, the NVD, and OSV?
The CVE List is the identifier registry, NVD is the U.S. government's enrichment and scoring layer on top of it, and OSV.dev is an open-source-focused database that adds precise version-range data the other two often lack. MITRE's cve.org publishes the bare CVE record. NVD, at nvd.nist.gov, adds CVSS scores and CPE strings but has historically described affected versions using CPE match strings that are notoriously imprecise for package ecosystems like npm or PyPI. OSV, launched by Google in 2021, was built specifically to fix that gap: it aggregates ecosystem-native advisories — the PyPA Advisory Database, the Go Vulnerability Database, RustSec, GitHub Security Advisories (GHSA) — and expresses affected ranges in semver-compatible commit and version ranges that scanners can match programmatically without manual normalization. A single flaw, such as CVE-2024-3094 (the xz-utils backdoor discovered March 29, 2024), typically ends up represented in all three simultaneously, each with slightly different metadata completeness.
Why did the 2024 NVD backlog crisis matter to security teams?
It mattered because for roughly nine months, most newly published CVEs sat unscored, which broke automated severity-based triage for any team relying on NVD's CVSS data. On February 12, 2024, NVD abruptly and without prior announcement slashed its rate of CVE analysis, and by mid-2024 independent trackers estimated a backlog exceeding 20,000 unanalyzed CVEs — records that existed in the database with no CVSS score, no CWE classification, and no CPE match string. Teams whose pipelines auto-filtered "CVSS >= 7" tickets for triage effectively stopped seeing new critical vulnerabilities flow into that filter, because the score field was simply blank. NIST attributed the slowdown to an increase in submission volume and "a change in interagency support," and brought on additional contractor support through 2024 to work the backlog down, but the incident is the clearest recent proof that a vulnerability database's usefulness depends as much on analyst throughput as on the underlying CVE data itself.
How current are severity scores across different vulnerability databases?
Severity scores are frequently stale or version-mismatched because CVSS itself has four major revisions in circulation and databases update on independent, uncoordinated schedules. CVSS 2.0 shipped in 2007, 3.0 in 2015, 3.1 in 2019, and 4.0 in November 2023, and NVD as of 2024 still publishes CVSS 2.0 scores for many pre-2016 records alongside 3.1 scores for newer ones — meaning two vulnerabilities of comparable real-world severity can carry scores computed on different scales. Layered on top of raw severity, FIRST's Exploit Prediction Scoring System (EPSS), now on version 3 since March 2023, adds a daily-refreshed probability (0 to 1) that a given CVE will be exploited in the next 30 days, which is a materially different signal from CVSS's static "how bad could this be" rating. CISA's Known Exploited Vulnerabilities (KEV) catalog, launched November 2021 and holding more than 1,300 entries by late 2024, is the third data point teams increasingly require alongside CVSS and EPSS, because it confirms actual observed exploitation rather than theoretical risk.
Which vulnerability databases should a security team actually track?
A security team should track at minimum five sources for a complete vulnerability database CVE picture, because no single database has complete coverage: NVD for CVSS/CPE enrichment, MITRE's CVE List as the canonical ID registry, OSV.dev for precise open-source version ranges, GitHub Advisory Database (GHSA, launched 2019) for ecosystem advisories often surfaced before NVD enrichment completes, and CISA KEV for confirmed-exploited flaws that should jump any patch queue regardless of CVSS score. Cloud-native and container-focused teams typically add vendor feeds too — Red Hat's OVAL data, Debian's Security Tracker, or Alpine's secdb — since distro-specific backport status determines whether a CVE is actually exploitable in a given image, independent of what the upstream record says. The practical failure mode for most teams isn't a lack of data; it's reconciling five differently-formatted, differently-paced feeds into one prioritized list without either drowning in false positives or missing a KEV-listed flaw that has no CVSS score yet.
How Safeguard Helps
Safeguard treats raw vulnerability database output as a starting point, not an answer, by running reachability analysis to determine whether a flagged package's vulnerable function is actually called from your code paths — collapsing the noise from thousands of NVD/OSV matches down to the fraction that pose real risk. Griffin AI cross-references CVSS, EPSS, and CISA KEV status alongside that reachability signal to rank findings the way a senior analyst would, rather than by static score alone. Safeguard generates and ingests SBOMs so every dependency is already mapped to CVE, GHSA, and OSV identifiers before a new advisory even lands, eliminating the manual reconciliation step described above. When a real, reachable vulnerability is confirmed, Safeguard can open an auto-fix pull request with the minimum version bump needed to remediate it, turning a database lookup into a merged fix without a manual triage cycle.