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 Submit pull requests to help improve our database of software vulnerability information for all

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

Features All advisories acknowledged by GitHub are stored as individual files in this repository. They are formatted in the Open Source Vulnerability (OSV) format You can submit a pull request to this database (see, Contributions) to change or update the information in each advisory Pull requests will be reviewed and either merged or closed by our internal security advisory curation team. If the advisory originated from a GitHub repository we will also @mention the original publisher for optional commentary

Sources We add advisories to the GitHub Advisory Database from the following sources: - Security advisories reported on GitHub The National Vulnerability Database The npm Security Advisories Database The FriendsOfPHP Database The Go Vulnerability Database The Python Packaging Advisory Database The Ruby Advisory Database The RustSec Advisory Database Community contributions to this repository If you know of another database we should be importing advisories from tell us about it by opening an issue in this repository

Contributions 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 shown below 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

Alternatively you can submit a pull request directly against a file in this repository To do so follow the contribution guidelines

Supported ecosystems Unfortunately we cannot accept community contributions to advisories outside of our supported ecosystems Our curation team reviews each community contribution thoroughly and needs to be able to assess each change Generally speaking, our ecosystems are the namespace used by a package registry. As such they’re focused on packages within the registry which tend to be dependencies used in software development Our supported ecosystems are: Composer (registry: https://packagist.org) Erlang (registry: https://hex.pm/) GitHub Actions (registry: https://github.com/marketplace?type=actions) Go (registry: https://pkg.go.dev/) Maven (registry: https://repo.maven.apache.org/maven2) npm (registry: https://www.npmjs.com/) NuGet (registry: https://www.nuget.org/) pip (registry: https://pypi.org/) Pub (registry: https://pub.dev/) RubyGems (registry: https://rubygems.org/) Rust (registry: https://crates.io/) Swift (registry: namespaced by dns) If you have a suggestion for a new ecosystem we should support, please open an issue for discussion.

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

GHSA IDs Each security advisory regardless of its type 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 All letters are lowercase You can validate a GHSA ID using a regular expression: /GHSA(-[23456789cfghjmpqrvwx]{4}){3}/

FAQ Who reviews the pull requests? Our internal Security Advisory Curation team reviews the pull requests. They make the ultimate decision to merge or close. If the advisory originated from a GitHub repository we will also @mention the original publisher for optional commentary ### Why is the base branch changed on a PR? This repository is a mirror of our advisory database. All contributions to this repository are merged into the main branch via our primary data source to preserve data integrity We automatically create a staging branch for each PR to preserve the GitHub workflow you're used to. When a contribution is accepted from a PR in this repository, 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 ### Will the structure of the database change? Here at GitHub we ship to learn! As usage patterns emerge we may iterate on how we organize this database and potentially make backwards-incompatible changes to it ### Where can I get more information about GitHub advisories?lInformation about creating a repository security advisory can be found here, and information about browsing security advisories in the GitHub Advisory Database can be found here.