A community-curated corpus of CVE and GHSA records in OSV format that defenders and authorized security teams can query, diff, and integrate into dependency management pipelines.
| Tool | github/advisory-database — open repository of security advisories covering CVEs and GitHub-originated vulnerabilities in open source software |
| Category | Vulnerability intelligence / OSV-formatted advisory data |
| Primary Use | Feeding SCA scanners, Dependabot-style alerting, and vulnerability research pipelines with machine-readable OSV records keyed by GHSA and CVE identifiers |
| Safe Use | Purely defensive dataset for authorized security teams, blue-team monitoring, patch prioritization, and research into open source dependency risk |
| Telemetry Note | Not a scanning tool — it leaves no footprint on target systems; its use is observable only as read traffic (git clones, API pulls) from your analysis infrastructure |
Most security teams treat vulnerability feeds as plumbing — something that arrives via Dependabot alerts or an SCA vendor and is rarely inspected at the source. github/advisory-database is that source, published openly by GitHub under a CC-BY-4.0 license. It is a git repository where every acknowledged advisory is stored as an individual file in the Open Source Vulnerability (OSV) format, and at roughly 2.5k stars it has become one of the reference datasets for anyone building dependency-analysis tooling. The premise is simple and worth internalizing: vulnerability intelligence you can clone, diff, and audit is far more valuable to a defender than intelligence trapped behind a portal.
The stated goals in the README are threefold: provide a free and open-source repository of security advisories, let the community crowd-source knowledge about them, and surface vulnerabilities in an industry-accepted format for machine interoperability. That third goal is the operationally important one. Because every record conforms to the OSV schema, the database slots directly into the growing ecosystem of OSV consumers — dependency scanners, SBOM analysis pipelines, and tooling built against osv.dev. You are not parsing prose advisories; you are parsing structured JSON with affected package identifiers, version ranges, and severity data.
GitHub is deliberately not the sole origin of the data. The README enumerates its upstream sources: repository security advisories reported on GitHub itself, the NVD, the npm security advisories database, FriendsOfPHP, the Go vulnerability database at vuln.go.dev, the Python Packaging Advisory Database from pypa, the RubySec Ruby advisory database, and RustSec. In other words, this is a convergence layer — it normalizes ecosystem-specific feeds into one schema and then layers GitHub's own curation on top. If you know of another database worth importing, the maintainers accept suggestions via issues, which tells you the ingest surface is still expanding.
The curation model is the interesting architectural detail. Pull requests against the repository are reviewed by GitHub's internal Security Advisory Curation team, who make the final merge-or-close call, and if an advisory originated from a GitHub repository the original publisher gets @mentioned for optional commentary. That two-layer review — community submission plus professional curator — is what distinguishes the github_reviewed records from raw mirroring. The database_specific field github_reviewed and its companion github_reviewed_at timestamp let you filter the corpus down to advisories a human curator has actually vetted, which matters when you are deciding what to feed into alerting versus what needs manual triage.
Each advisory carries a unique GHSA ID in the format GHSA-xxxx-xxxx-xxxx, where the characters are drawn from the restricted set 23456789cfghjmpqrvwx and all letters are lowercase. The README even supplies the validation regex /GHSA(-[23456789cfghjmpqrvwx]{4}){3}/, a small but telling detail: they expect programmatic consumers and give them the grammar to validate identifiers. Every advisory, regardless of whether it originated as a CVE or from an ecosystem database, gets one of these IDs at creation, so GHSA acts as the universal join key across the dataset.
The database_specific extension mechanism deserves attention from anyone writing a parser. The OSV schema allows custom JSON objects scoped to the vulnerability, an affected package, or an affected range, and GitHub uses several: a human-readable severity in addition to quantitative CVSS scores, cwe_ids mapping to the MITRE CWE database, and last_known_affected_version_range for version-range semantics that native OSV cannot express. The README is blunt that these fields are for internal use and may change without notice — consuming systems should not build logic on them. Treat them as enrichment, and build your core matching logic on the stable OSV fields.
Contribution flow has some non-obvious mechanics documented in the FAQ. From any advisory page on github.com/advisories, clicking Suggest improvements opens a form whose submission becomes a pull request. More significantly, the public repository is a mirror: accepted PRs are merged into a staging branch, pushed to GitHub's primary internal data source, and then merged back to main by a separate process to preserve data integrity. This is why the base branch on your PR may appear to change. Practically, it means the repo you clone is a continuously synchronized projection of the live database, refreshed on GitHub's own pipeline cadence rather than on community merge timing.
Scope is bounded by supported ecosystems, and the README is explicit that community contributions cannot be accepted outside them. The list covers Composer/packagist, Erlang/hex.pm, GitHub Actions, Go, Maven, npm, NuGet, pip/pypi, Pub, RubyGems, Rust/crates.io, and Swift with DNS-namespaced identifiers. The framing is registry-based — ecosystems are package namespaces, focused on development dependencies. Notably absent are Linux distributions and container base images, so this corpus answers the question "is my dependency tree affected?" rather than "is my OS package set affected?"
The contribution guidelines on references and fix commits reveal the editorial philosophy. References should be primary sources from the CVE or GHSA authors, supplemented with relevant code or documentation, with secondary write-ups generally avoided. Fix-commit references are explicitly welcomed because advisories are about specific build artifacts, not projects generally — knowing the exact commit that patched a vulnerability lets downstream readers determine real impact. The curators reject duplicative fix-commit additions, reasoning that redundant content burdens the reader. This is data hygiene as policy, and it is why the corpus stays trustworthy at scale.
For defenders integrating this into an authorized workflow, the obvious pattern is cloning the repository on a schedule, parsing the OSV JSON, and matching affected ranges against your SBOM or lockfiles. Because the schema is standardized, you can substitute or cross-check against osv.dev, the NVD, or ecosystem-native feeds to catch divergence. The cwe_ids field, even though nominally internal, is useful for weakness-trend analysis — identifying which CWE classes dominate a given ecosystem over time. None of this touches any target system; it is pure intelligence work performed on your own infrastructure.
The FAQ closes with a caveat that should shape your architecture: GitHub states plainly that they "ship to learn" and may make backwards-incompatible changes to how the database is organized. Pin your parser to the OSV schema, not to the repository layout, and expect the directory structure to evolve. Combined with the instability warning on database_specific values, the message is clear — the stable contract is OSV plus GHSA identifiers, and everything else is implementation detail. For anyone building supply-chain defense tooling, github/advisory-database remains the most accessible ground truth for open source vulnerability intelligence, and reading its README end to end is a worthwhile exercise in understanding where your Dependabot alerts actually come from.
github/advisory-database.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.