When a maintainer patches a silent security bug in a popular npm package, that fix doesn't automatically become a vulnerability record the rest of the world can query. Someone has to notice it, describe it, assign it a severity score, map it to affected version ranges, and publish it in a machine-readable format — and increasingly, that "someone" is GitHub itself. The GitHub Advisory Database (GHSA) has quietly become one of the most consulted vulnerability sources in the software supply chain, feeding Dependabot alerts, npm audit, and countless third-party scanners. But the database is not a neutral wire service. It's a curated product, built by a mix of automated ingestion, GitHub Security Lab researchers, and community submissions — each with different review standards, timelines, and blind spots. Understanding how a record actually gets made changes how much you should trust it at face value.
How Does a Vulnerability Enter the GitHub Advisory Database?
A vulnerability enters GHSA through one of three doors: GitHub's own security research team, a repository maintainer filing a private security advisory, or automated syncing from the National Vulnerability Database (NVD) and MITRE's CVE list. GitHub Security Lab, launched in 2019, contributes original research — often the result of CodeQL-based variant analysis across open-source repositories — and these tend to carry the most detailed write-ups, including proof-of-concept queries. The far larger volume, however, comes from maintainer-initiated advisories: a project owner uses GitHub's built-in "Security Advisories" feature to privately draft a report, coordinate a fix, and request a CVE ID before disclosure. Since GitHub became a CVE Numbering Authority (CNA) in September 2020, it can issue CVE IDs directly for advisories on GitHub-hosted repositories, which is why so many npm, PyPI, and RubyGems CVEs now originate on GitHub rather than through a separate CNA. The rest arrives via daily automated syncs from NVD, backfilling CVEs that were never reported through GitHub's own flow.
Who Actually Reviews an Advisory Before It's Published?
Review responsibility depends entirely on which of the two advisory tracks a record falls into: "GitHub-reviewed" or "unreviewed." GitHub-reviewed advisories go through a curation team that verifies the affected package, confirms version ranges against the actual registry (npm, Maven Central, PyPI, Go proxy, NuGet, crates.io, Composer, RubyGems, Pub, and Swift), and assigns a CVSS score using GitHub's own severity methodology, which can diverge from NVD's. This is the set that powers Dependabot alerts — as of the current schema, only reviewed advisories trigger automated Dependabot pull requests, because GitHub needs confidence in the ecosystem and range data before recommending an upgrade. Unreviewed advisories, by contrast, are pulled in largely as-is from NVD's CVE feed for packages GitHub hasn't independently curated; they appear in search results and the API but are explicitly flagged as not verified for accuracy, and many carry incomplete or placeholder version-range data (>= 0 is a recurring artifact of automated NVD-to-GHSA translation). That distinction — reviewed versus unreviewed — is the single most important thing to check before trusting a GHSA record's severity or "fixed in" version.
How Does GitHub Advanced Security Use This Database Differently Than the Public Feed?
GitHub Advanced Security (GHAS) consumes the same underlying advisory data but layers proprietary enrichment on top that the free public database doesn't expose. Dependabot, part of GHAS, cross-references reviewed advisories against a repository's dependency graph and generates version-range-aware alerts, but GHAS customers also get access to Dependabot's private vulnerability reporting workflow, secret scanning validity checks, and code scanning results correlated against the same CVE identifiers — a level of internal correlation that isn't available through the public github/advisory-database repository or the REST/GraphQL API alone. The practical effect is a two-tier system: any organization can pull the raw GHSA feed for free, but GHAS customers get the advisory data pre-fused with their actual code and dependency graph inside GitHub's UI. That's a meaningful convenience if you're fully committed to GitHub as your SCM, but it also means the depth of insight you get is coupled to buying GHAS specifically — the advisory data itself doesn't get better, only its presentation inside GitHub does.
What Gaps Exist Between GHSA Records and Real-World Exploitability?
The database is comprehensive on disclosure but thin on exploitability context, because GHSA's schema captures CVSS, affected ranges, and a text summary — not exploit maturity, reachability, or in-the-wild activity. A CVSS 9.8 entry for a deeply nested transitive dependency that's never invoked in your call path looks identical, in severity, to a 9.8 in a directly-imported package handling untrusted input. This is the same limitation that plagues NVD, but it matters more for GHSA because Dependabot alerts are triggered off it, so teams frequently end up prioritizing patches by raw CVSS rather than actual reachability. A well-known illustration was CVE-2021-44228 (Log4Shell): the advisory correctly flagged the severity, but organizations without dependency-graph tooling couldn't quickly tell which of their services actually loaded the vulnerable JndiLookup class versus which merely had log4j-core sitting unused in a fat JAR. GHSA also lags on ecosystems it doesn't natively index well — container base images, OS packages, and infrastructure-as-code modules aren't covered by GHSA's application-package focus, leaving a blind spot for teams relying on it as a single source of truth.
How Fresh and Accurate Is the "Fixed In" Version Data?
Freshness varies sharply between reviewed and unreviewed advisories, with reviewed records typically updated within days of a new patch release but unreviewed ones sometimes stuck with the version data from initial NVD publication. GitHub's curation team monitors registry release feeds for actively reviewed advisories, so when a maintainer ships a point release like 4.2.1 to fix what 4.2.0 broke, the reviewed advisory's affected-range gets updated to reflect it. Unreviewed advisories don't get that follow-up unless someone files a correction through GitHub's public advisory-database GitHub repository, where users can open pull requests against the OSV-formatted JSON files directly. This crowdsourced-correction path is a real strength — the database is open source and accepts community PRs — but it also means accuracy for the long tail depends on volunteer attention rather than a guaranteed SLA, and low-profile ecosystems (Pub, Swift, and some Go modules) see much slower correction cycles than npm or PyPI.
How Safeguard Helps
Safeguard treats the GitHub Advisory Database as one input among several, not the finish line. Rather than surfacing a raw CVSS score and calling it prioritization, Safeguard correlates GHSA and NVD data against your actual dependency graph and call-path reachability, so a critical advisory in an unreachable transitive dependency doesn't consume the same triage attention as one sitting directly in your request-handling code — closing exactly the gap that turned Log4Shell response into a scramble for teams without that visibility. Safeguard also reconciles discrepancies between GitHub-reviewed and unreviewed advisories automatically, flagging cases where affected-version ranges look stale or where an NVD-sourced record hasn't been cross-checked against the actual registry release history, so you're not silently trusting a placeholder >= 0 range. And because Safeguard isn't scoped to GitHub-hosted repositories or GHAS licensing, it extends the same curated, reachability-aware vulnerability intelligence to container images, OS packages, and infrastructure code that GHSA's application-package focus doesn't cover — giving you one consistent severity and remediation signal across the parts of your supply chain that GitHub's advisory pipeline was never built to see.