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.
- 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.
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.
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.
This project is licensed under the terms of the CC-BY 4.0 open source license. Please see our documentation for the full terms.
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.
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.
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.