When a new vulnerability surfaces in an open source package, the first question security teams ask is simple: is this actually a CVE, and do we have enough context to act on it? The answer is more complicated than it looks. The National Vulnerability Database (NVD) publishes raw CVE records, but a raw CVE ID alone often arrives without affected version ranges, patched versions, or ecosystem-specific context — and NVD has publicly acknowledged periods of reduced analysis throughput that leave records unenriched for stretches of time. GitHub's Advisory Database was built to close part of that gap: it curates more than 30,000 advisories, mapped to specific package ecosystems, with GitHub-reviewed severity and remediation data. GitHub Advanced Security (GHAS) is the commercial product that surfaces this data inside GitHub via Dependabot alerts. This post compares what the Advisory Database actually covers, where GHAS inherits its limits, and where Safeguard fits for teams that need coverage beyond a single ecosystem-scoped source.
What Is the GitHub Advisory Database, and How Is It Different from Raw CVE Data?
Raw CVE data, as distributed through NVD, is a flat identifier system: a CVE number, a short description, and — eventually — CPE (Common Platform Enumeration) matching and a CVSS score once NIST analysts process it. It covers everything from enterprise software to firmware, network appliances, and industrial control systems, which makes it broad but not structured around any particular software ecosystem.
The GitHub Advisory Database narrows that scope deliberately. Every entry is tied to a specific package ecosystem — npm, RubyGems, PyPI, Maven, NuGet, Composer, Go modules, crates.io, Pub, and others supported by Dependabot — and each advisory includes structured fields: affected version ranges, first patched version, a GitHub-assigned severity rating, and links to the originating fix commit or release where available. That structure is what lets Dependabot alerts fire automatically when a manifest or lockfile matches a vulnerable range. A raw CVE record, by contrast, has no guaranteed version-range field at all; mapping a CVE to "is my dependency affected" is left to whoever consumes it.
The practical difference is this: GitHub's database is a curated, ecosystem-scoped subset built for actionability inside dependency graphs, while CVE/NVD is a broader, less structured identifier registry that spans far more than software packages.
Does Every Advisory in GitHub's Database Have a CVE ID?
No, and this is a concrete, verifiable distinction worth understanding. GitHub can mint a GHSA (GitHub Security Advisory) identifier for a repository-reported vulnerability without a corresponding CVE ever being assigned by a CNA (CVE Numbering Authority). GitHub itself operates as a CNA and can assign CVEs to some of these, but plenty of GHSA entries — particularly for smaller or less widely used packages — exist as GHSA-only records. If your vulnerability management program only ingests CVE feeds, these GHSA-only advisories will never appear in your data, even though they represent real, documented, fixable issues in packages you may depend on.
This matters operationally. A scanner or alerting pipeline that filters strictly on "has a CVE ID" will systematically under-report supply chain risk relative to one that also ingests GHSA identifiers directly.
How Does GitHub Advanced Security Use This Data, and Where Does That Coverage Stop?
GHAS's Dependabot alerts are powered directly by the GitHub Advisory Database — this is documented in GitHub's own product materials. That's a meaningful advantage for repositories hosted on GitHub with dependency graph enabled: alerts are generated from the same curated dataset described above, with version-range matching against your manifest files.
The coverage boundary follows from the source: because the Advisory Database is scoped to ecosystems Dependabot understands, vulnerabilities in software components that fall outside those ecosystems — OS-level packages inside container base images, statically linked binaries, vendored C/C++ libraries without a package-manager manifest, or internal artifacts not expressed as a supported manifest format — are not covered by Dependabot alerts in the same way, regardless of whether GHAS is enabled. This isn't a criticism of GHAS's implementation; it's a direct consequence of what the underlying advisory database is designed to index. Teams running mixed environments — GitHub repos alongside container registries, VM images, or non-GitHub source control — need to know where that boundary sits before treating Dependabot alert silence as an all-clear.
What Happens When NVD Enrichment Lags Behind Disclosure?
NIST publicly acknowledged in 2024 that NVD's analysis and enrichment throughput had slowed, leaving a backlog of CVE records published without CPE matching or CVSS scoring for extended periods. For any tool that depends purely on NVD's enriched fields — CPE-based matching in particular — that backlog translates directly into delayed or missing alerts, through no fault of the scanning tool itself.
The GitHub Advisory Database is not dependent on NVD's enrichment pipeline for its own severity and version-range data; GitHub's curation team (and community contributors, subject to review) populate those fields independently. That makes it a useful supplementary source during periods when NVD enrichment is delayed. It does not, however, expand the ecosystem scope described above — it's a different, narrower pipeline with its own review process, not a superset of CVE data.
Should You Rely on One Advisory Source, or Correlate Several?
This is the question that matters most for a supply chain security program, and it's less about which single source is "better" and more about coverage math. The GitHub Advisory Database, OSV.dev, vendor security advisories (npm's own advisories, RustSec, PyPA advisory database), Linux distribution security trackers (Debian, Alpine, Red Hat), and NVD's CVE feed each have different scopes, different review cadences, and different identifier schemes (GHSA, OSV IDs, distro-specific IDs, CVE). A vulnerability disclosed first in a distro tracker may take time to appear as a GHSA; conversely, a GHSA-only advisory with no CVE will never show up in a pure NVD feed. None of these sources is a strict superset of the others.
Any program relying on a single feed — whether that's raw CVE/NVD or the GitHub Advisory Database alone — inherits that feed's specific blind spots. The only way to close them is correlation across sources, with deduplication so the same underlying flaw isn't triple-counted under three identifiers.
How Safeguard Helps
Safeguard is built around the premise that no single advisory source is sufficient on its own, so it correlates the GitHub Advisory Database alongside OSV, NVD/CVE, and ecosystem- and distro-specific advisory feeds into one normalized view, mapping GHSA, OSV, and CVE identifiers to the same underlying finding so teams aren't triaging duplicate alerts for one vulnerability. Because Safeguard ingests advisories directly from GHSA and OSV rather than filtering strictly on CVE presence, GHSA-only advisories without an assigned CVE are surfaced rather than silently dropped.
Safeguard also extends coverage beyond the package-manifest ecosystems that Dependabot-driven tooling is scoped to, matching findings against SBOMs generated from container images, OS packages, and non-npm/PyPI/Maven-style dependency trees — so components that fall outside GitHub's Advisory Database scope are still tracked against whichever advisory sources do cover them. When one upstream source is enriched more slowly than another — as has been publicly documented with NVD's analysis backlog — Safeguard's multi-source correlation means a delay in one feed doesn't translate into a blind spot for teams relying on Safeguard's aggregated view.
For teams already using GitHub Advanced Security, this isn't an either/or decision: Dependabot alerts remain a strong, native signal for GitHub-hosted repositories within supported ecosystems. Safeguard is designed to sit alongside that signal, correlating it with additional sources and extending visibility to the parts of the software supply chain — container base images, vendored binaries, non-GitHub-hosted code, distro packages — that sit outside any single advisory database's scope. The goal is the same one that drove GitHub to build a curated advisory layer on top of raw CVE data in the first place: turning fragmented vulnerability identifiers into something a security team can actually act on, without gaps introduced by relying on just one source.