This attributed fork of the GitHub Advisory Database explores how public vulnerability records connect identifiers, affected packages, and references. A synthetic review queue makes capacity assumptions visible.
Native-source lesson guide · Offline interactive lab · Lesson configuration · Configuration schema
Open the previous-animation gallery · Local gallery
Earlier animated artwork, waveform demos, and original interactive experiences are linked alongside the current animations.
- Download or clone this repository and open
docs/index.htmlin a modern browser. - Select Module 1, apply its preset, and compare the declared checkpoint with the plotted result.
- Change one slider, inspect the model assumptions, then export the configuration or telemetry for your notes.
The browser lab runs offline with no packages, accounts, or live data feeds. Its numbers are deterministic teaching simulations. Each checkpoint states its model time and tolerance; passing it demonstrates agreement with that model, not field calibration or production readiness.
| Module | Investigation | Approximate time |
|---|---|---|
| 1. Read a record before counting it | Separate advisory identifiers, public evidence, and review throughput. | 12 min |
| 2. Plan capacity without losing provenance | Calculate the staffing needed for a fixed review demand. | 12 min |
| 3. Stress the automation assumption | Explain why a capacity improvement is conditional on correct automated decisions. | 15 min |
| 4. Write a defensible triage handoff | Document a bounded capacity scenario while preserving the upstream contribution boundary. | 15 min |
Who this is for: Developers, dependency maintainers, and learners beginning defensive vulnerability-data review.
- README.md
- CONTRIBUTING.md
- LICENSE.md
- SECURITY.md
- .github/workflows/create_staging_branch.yaml
- .github/workflows/delete_staging_and_head_branches.yaml
Git for structural reading; the browser lesson has no installation requirement.
git show HEAD:README.md
git ls-tree -d HEAD advisories
git ls-tree HEAD advisories/github-reviewedThese commands come from the audited source revision. Runtime requirements and the project's own validation limits are documented below; the standalone browser lab does not execute these commands.
Fork provenance. This repository retains the upstream project and its attribution. https://github.com/github/advisory-database The interactive lab is an additional educational companion; it does not imply upstream endorsement or relicense the existing material.
The detailed project guide below remains the source for installation, supported features, licences, and scientific limits. The browser equations and laboratory settings do not change the original application or numerical engine.
Project documentation, installation, attribution, and existing validation
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.
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.
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.
Advisory references are intended to be supplemental, relevant information for the reader. We aim 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. We generally avoid including secondary source write ups on advisories unless they are provided by the upstream source.
Advisories are about specific build artifacts, and not about the project more generally. A reference to the commit that fixes a given vulnerability is helpful for downstream readers to determine impact, and we welcome contributions adding these details when missing. If the advisory already includes the relevant fix commit(s), we do not accept contributions that are duplicative, as adding irrelevant duplicate content creates an unnecessary burden on the reader of an advisory.
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.
This project is licensed under the terms of the CC-BY 4.0 open source license. Please see our documentation for the full terms.
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
xis a letter or a number from the following set:23456789cfghjmpqrvwx.- Outside the
GHSAportion 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}/
The OSV Schema supports several database_specific JSON object fields that are used to add context to various other parts of the OSV schema, namely an affected package, a package's affected ranges, and the vulnerability as a whole. Per the spec, these fields are used for holding additional information about the package, range, or vulnerability "as defined by the database from which the record was obtained." It additionally stipulates that the meaning and format of these custom values "is entirely defined by the database [of record]" and outside of the scope of the OSV Schema itself.
For its purposes, GitHub uses a number of database_specific values in its OSV files. They are used primarily in support of Community Contributions and are intended for internal use only unless otherwise specified. These values and their format are subject to change without notice. Consuming systems should not rely on them for processing vulnerability information.
| Scope | Field | Purpose |
|---|---|---|
| vulnerability | severity |
The OSV schema supports quantitative severity scores such as CVSS. GitHub additionally assigns each vulnerability a non-quantitative human-readable severity value. |
| vulnerability | 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. |
| vulnerability | github_reviewed |
Whether a vulnerability has been reviewed by one of GitHub's Security Curators. |
| vulnerability | github_reviewed_at |
The timestamp of the last review by a GitHub Security Curator. |
| range | last_known_affected_version_range |
The OSV schema does not have native support for all of the potential ways GitHub represents vulnerabile version ranges internally. It is used to track version range information that is not representable in OSV format, or that GitHub needs to be able to track separately from the OSV ranges. This field may appear in addition to or in place of OSV affected range events. See this comment a technical explanation. |
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.
Information about creating a repository security advisory can be found GitHub advisory creation guide, and information about browsing security advisories in the GitHub Advisory Database can be found GitHub advisory browsing guide.