What is the GitHub advisory database, and how does it help you secure dependencies?

Anatomy of the GitHub Advisory Database

The GitHub Advisory Database is a catalog of known security vulnerabilities and malware affecting open source packages. It organizes its content into three categories:

• GitHub-reviewed advisories: Manually reviewed vulnerabilities mapped to packages in supported ecosystems.
• Unreviewed advisories: Automatically ingested from the National Vulnerability Database (NVD). Despite the name, many are reviewed by GitHub analysts, but they don’t qualify as reviewed advisories because they either aren’t in a supported package ecosystem or don’t describe a valid vulnerability.
• Malware advisories: Threats identified by the npm security team, currently exclusive to the npm ecosystem. GitHub doesn’t edit or accept community contributions for this category.

The database has grown from fewer than 400 reviewed advisories five years ago to more than 20,000 as of October 2024. That growth stems from more incoming reports, expanded ecosystem support, and campaigns to review advisories published before the database existed.

Ecosystem Distribution

Reviewed advisories are restricted to vulnerabilities in packages that come from supported registries, which are generally named after the associated programming language’s package registry.

Maven and Composer packages account for nearly half of all advisories. npm, pip, and Go contribute much of the remainder, while the remaining ecosystems hold a much smaller share. That distribution has shifted considerably since launch—npm originally dominated the database, but broader ecosystem coverage has rebalanced the mix.

Where Advisories Come From

Advisories enter the database through four main channels:

• NVD: The largest single source, covering all software types. GitHub publishes every NVD advisory but only reviews ones relevant to supported ecosystems.
• GitHub Repository Advisories: The second-largest source, originating through GitHub’s repository security advisory feature. These focus exclusively on open source software, so coverage is better even though they aren’t restricted to supported ecosystems.
• Community Contributions: Reports from users, nearly all requesting updates to existing advisories.
• Other Specialized Sources: Ecosystem-specific feeds such as PyPA Advisories for Python and Go Vulncheck for Go. Because these only cover packages within supported ecosystems, most qualify for review.

Summing the reviewed advisories from each source yields a total larger than the actual reviewed count. That’s because multiple sources often flag the same vulnerability—over half of advisories have more than one source. Of those with just one source, the overwhelming majority come from NVD/CVE, the noisiest source, which still justifies its inclusion.

Imports from all sources rose 39% in 2024, driven mainly by an increase in published CVE records.

CVE Numbering Authority Role

Beyond the Advisory Database, GitHub operates as a CVE Numbering Authority (CNA) for any repository hosted on the platform. This lets GitHub issue CVE IDs for vulnerabilities reported by maintainers and publish the records to the broader CVE database once a repository advisory goes live.

GitHub published more than 2,000 CVE records in 2024, making it the fifth-largest CNA in the CVE Program. This CNA service is open to all repositories, not just those in supported ecosystems.

Prioritizing with CVSS, CWE, and EPSS

The volume of reported vulnerabilities makes prioritization essential. GitHub supplements each advisory with three data points to help triage:

• Severity Rating/CVSS: A rating from low to critical, with a corresponding CVSS score and vector.
• CWE: Identifiers that programmatically classify the type of vulnerability.
• EPSS: The Exploit Prediction Scoring System, devised by FIRST, which scores the likelihood a vulnerability gets exploited within 30 days.

Every advisory gets a severity rating drawn from the four levels defined in the Common Vulnerability Scoring System: Low, Medium/Moderate, High, and Critical. According to these ratings, half of all vulnerabilities—15% Critical and 35% High—warrant immediate or near-term remediation attention.

CVSS base scores reflect intrinsic characteristics constant over time and assume a reasonable worst-case impact across varied environments. Your own worst case might differ, though—a crash in a word processor isn’t as severe as one in a server. To filter alerts by vulnerability type, GitHub supports CWE identifiers. That allows filtering out recurring issues like regular expression denial of service (CWE-1333) or always surfacing SQL injection (CWE-89).

When that’s insufficient, EPSS can help narrow the field further. It synthesizes data from multiple sources into a probability that a given vulnerability faces exploitation attempts in the next 30 days. Focusing on vulnerabilities with an EPSS score of 10% or higher—about 7% of all entries in the Advisory DB—covers nearly all vulnerabilities likely to see active exploit traffic.

EPSS comes with caveats worth remembering:

• Low-probability events still occur.
• EPSS measures likelihood, not confirmed exploitation.
• Scores update daily and shift as new information emerges; today’s low-probability vulnerability could become high-probability tomorrow.

How Dependabot Uses the Data

The Advisory Database powers more than just a reading list. Services like Dependabot leverage it to automate dependency security:

• Identify vulnerabilities: Flag projects using affected package versions.
• Suggest fixes: Recommend updated versions that resolve the vulnerability.
• Reduce noise: Alert only when the installed version is actually impacted.

For maintainers, publishing a repository security advisory is the direct path to tap both the Advisory Database and GitHub’s CNA services, ensuring vulnerabilities reach the broader CVE community.