Skip to content
Cobalt Rentals

GitHub Advisory Database

A database of CVEs and GitHub-originated security advisories affecting the open source world. The database is free and open source and is a tool for and by the community.

Overview

The GitHub Advisory Database provides a free and open-source repository of security advisories. All advisories acknowledged by GitHub are stored as individual files in this repository, formatted in the Open Source Vulnerability (OSV) format.

You can submit a pull request to this database to change or update the information in each advisory. Pull requests will be reviewed and either merged or closed by GitHub's internal security advisory curation team. If the advisory originated from a GitHub repository, the original publisher will be @mentioned for optional commentary.

Goals

  • To provide a free and open-source repository of security advisories.
  • To enable the community to crowd-source their knowledge about these advisories.
  • To surface vulnerabilities in an industry-accepted formatting standard for machine interoperability.

Advisory Sources

GitHub adds advisories to the GitHub Advisory Database from the following sources:

If you know of another database that should be imported, open an issue in this repository.

Contributing

There are two ways to contribute to the information provided in this repository.

From any individual advisory on github.com/advisories, click Suggest improvements for this vulnerability to open an "Improve security advisory" form. Edit the information in the form and click Submit improvements to open a pull request with your proposed changes.

Screen shot showing the "Suggest improvements for this vulnerability" link in the right sidebar

Alternatively, you can submit a pull request directly against a file in this repository by following the contribution guidelines.

Advisory References

Advisory references are intended to be supplemental, relevant information for the reader. GitHub aims to include primary source references provided by the CVE or GHSA authors, supplement with relevant code or documentation when applicable, and focus on concision and relevance for any additional references. Secondary source write-ups on advisories are generally avoided unless they are provided by the upstream source.

Advisories are about specific build artifacts, not the project more generally. A reference to the commit that fixes a given vulnerability is helpful for downstream readers to determine impact. Duplicate or irrelevant content is not accepted, as it creates an unnecessary burden on the reader of an advisory.

Supported Ecosystems

Community contributions to advisories outside of GitHub's supported ecosystems cannot be accepted. GitHub's curation team reviews each community contribution thoroughly and needs to be able to assess each change.

Supported ecosystems are generally the namespace used by a package registry, focused on packages within the registry that tend to be dependencies used in software development:

If you have a suggestion for a new ecosystem to support, please open an issue for discussion.

GHSA IDs

Each security advisory has a unique identifier referred to as a GHSA ID. A GHSA-ID qualifier is assigned when a new advisory is created on GitHub or added to the GitHub Advisory Database from any of the supported sources.

The syntax of GHSA IDs follows this format: GHSA-xxxx-xxxx-xxxx where:

  • x is a letter or a number from the following set: 23456789cfghjmpqrvwx.
  • Outside the GHSA portion of the name, the numbers and letters are randomly assigned and all letters are lowercase.

You can validate a GHSA ID using the regular expression: /GHSA(-[23456789cfghjmpqrvwx]{4}){3}/

Database-Specific Values

The OSV Schema supports several database_specific JSON object fields used to add context to affected packages, affected ranges, and vulnerabilities. GitHub uses a number of database_specific values in its OSV files, primarily in support of community contributions and intended for internal use only unless otherwise specified. These values and their format are subject to change without notice, and consuming systems should not rely on them for processing vulnerability information.

Vulnerability fields:

  • severity: GitHub assigns each vulnerability a non-quantitative human-readable severity value in addition to quantitative severity scores such as CVSS. - cwe_ids: GitHub assigns each vulnerability at least one Common Weakness Enumeration (CWE) as part of its vulnerability curation process. These IDs map directly to CWE IDs tracked in the CWE Database. - github_reviewed: Whether a vulnerability has been reviewed by one of GitHub's Security Curators. - github_reviewed_at: The timestamp of the last review by a GitHub Security Curator.

Range fields:

  • last_known_affected_version_range: The OSV schema does not have native support for all of the potential ways GitHub represents vulnerable version ranges internally. This field tracks version range information that is not representable in OSV format, or that GitHub needs to track separately from the OSV ranges. It may appear in addition to or in place of OSV affected range events. See this technical explanation for details.

Repository Structure

This repository is a mirror of GitHub's advisory database. All contributions are merged into the main branch via the primary data source to preserve data integrity. GitHub automatically creates a staging branch for each PR to preserve the GitHub workflow. When a contribution is accepted, the changes are merged into the staging branch and then pushed to the primary data source to be merged into main by a separate process, at which point the staging branch is deleted.

License

This project is licensed under the terms of the CC-BY 4.0 open source license. Please see the documentation for the full terms.

Additional Resources