When More Data Means More Work: Inside GitHub’s Vulnerability Curation Bottleneck

The Numbers Behind the Surge

In May 2026, GitHub published 1,560 reviewed advisories in a single month — more than five times its typical monthly output and the highest figure in the database’s history. By almost any measure, that sounds like success. It was also, simultaneously, not enough.

The intake side of the pipeline had grown even faster. Private vulnerability reports across the platform climbed from roughly 550 per week in January to more than 3,000 per week by May. Repository advisories scaled from around 650 per week to more than 5,000. CVE requests through GitHub’s CNA (Certificate Numbering Authority) role reached nearly 4,000 in May alone — approximately ten times the year-earlier figure. The CVE program as a whole had already published more than 30,000 CVEs in 2026.

None of this means the security landscape is collapsing. It means that more researchers are reporting vulnerabilities, more maintainers are disclosing fixes, and more repositories are enabling responsible disclosure channels. Greater transparency creates more records. More records require more curation. And curation, it turns out, does not scale automatically.

What Curation Actually Involves

To understand the bottleneck, it helps to understand what a "reviewed advisory" actually is — and why it differs from a raw report.

When a vulnerability report arrives, it might say a package called "foo" is affected. But is that foo on npm, python-foo on PyPI, or a completely different foo on Maven? When the upstream report does not specify, a curator has to determine the correct registry identity before anything else can happen. Without the precise package name as it appears in the registry, downstream tools cannot match the advisory against a project’s dependency graph to generate an alert.

Version ranges are similarly fragile. Many reports arrive with no affected version range at all, or with ranges that do not match actual release history. Curators trace commits, changelogs, and tagged releases to reconstruct what is genuinely affected. And when the CVE record, the maintainer’s advisory, and the commit history disagree with each other — which happens — someone has to determine which source is correct.

This is what normalization means in practice: turning a messy, incomplete, or ambiguous report into structured fields that software tools can compare and act on. A CVSS vector string, for instance, is not just a severity label like "High." It encodes attack complexity, required privileges, and user interaction into a structured format that allows automated tools to prioritize and compare vulnerabilities across large datasets. A CWE classification identifies the underlying weakness type — cross-site scripting, SQL injection, deserialization of untrusted data — giving downstream consumers a standardized way to filter and categorize issues without reading every narrative description.

From Raw Report to Reviewed Advisory

The table below illustrates how the same vulnerability looks at different stages of the pipeline.

A report in the left column cannot safely drive automated alerts. Publishing it as-is would mean false positives at scale — tools flagging packages that are not actually affected, or missing packages that are. As GitHub notes, publishing faster by skipping verification would increase false positives, which can create more risk than delay.

The Pipeline from Report to Alert

flowchart TD
 A[Incoming report\nPVR / Repo Advisory / CVE request] --> B[Triage and prioritization]
 B --> C[Human curation\npackage ID, version range, CVSS, CWE]
 C --> D[Reviewed advisory\npublished to database]
 D --> E[Dependabot alert\ntriggered for affected repos]

Dependabot, GitHub’s automated dependency alert system, only triggers alerts based on reviewed advisories. That single constraint is the reason the curation queue matters so much. An unreviewed report sitting in the pipeline is invisible to the millions of repositories relying on Dependabot for security signals. The gap between intake and review is therefore not an administrative inconvenience — it is a measurable exposure window during which a fix may exist but developers have not been warned.

A study of GitHub Security Advisories published between 2019 and 2025 found that only about 8% of the 288,604 advisories examined had completed GitHub’s formal review process. Those reviewed entries, however, play an outsized role: they are the ones that feed dependency scanners, alerting systems, and automated remediation tools. The asymmetry matters. A large unreviewed tail exists, but a small reviewed core carries most of the operational weight.

Why Not Just Add More Reviewers?

The straightforward response to a throughput problem is to add capacity, and GitHub is doing that — scaling backend curation systems, expanding documentation to onboard new team members faster, and deploying AI-assisted research tools to speed up the routine research phase of advisory review. The AI tools help curators find package identities, confirm version ranges, and cross-reference upstream data more quickly. Curators still make every decision; the tooling reduces time on predictable sub-tasks.

But the harder constraint is the mix of incoming work. Not all vulnerability reports require the same effort. A well-formatted advisory with clear package names, version ranges, and a fix already tagged can be validated in minutes. A multi-ecosystem advisory — say, a library that ships to both NuGet and npm, where a vulnerability in shared logic affects both implementations — requires independent verification across multiple registries and data sources. When volume surges, both easy and hard cases flood the queue simultaneously, and the complex cases take disproportionately longer, creating a compounding backlog effect.

The entry path also matters. Research on advisory timelines suggests that advisories created directly by maintainers inside GitHub repositories tend to move through review significantly faster than those imported from external sources like the NVD, partly because the pipeline structure gives repository advisories a more direct route to the review queue.

The Upstream Fix

This points toward a structural insight: the most effective way to reduce curation time is to improve the quality of reports before they arrive. When a researcher submits complete data — the registry-exact package name, a validated version range, a full CVSS vector string, a relevant CWE — the curator’s job shrinks from reconstruction to confirmation. At current volumes, that difference compounds across thousands of advisories per month.

GitHub’s own framing for this is "shared responsibility": the database is not a passive repository but an ecosystem where researchers, maintainers, and the curation team are jointly responsible for data quality. That framing reflects a real structural reality. A central curation team, however well-resourced, cannot substitute for accurate upstream data.

What This Means for the Broader Ecosystem

GitHub’s situation is a specific, well-documented case, and it would be a mistake to assume every security database faces identical constraints. What the case does illustrate is a general principle: the bottleneck in a vulnerability management pipeline is almost never collection. It is verification, normalization, and the maintenance of a trust boundary between raw reports and actionable data.

A security advisory database is only as useful as its curation pipeline can make it. Growing the intake faster than the curation capacity does not improve security — it creates a larger gap between what is known and what downstream tools can act on. The goal is not to process every report quickly; it is to publish accurate, structured, comparable records that automated systems can rely on without doing their own validation from scratch.

That standard is harder to meet at scale, and maintaining it under pressure is precisely the challenge GitHub is navigating. The record output of May 2026 is real progress. So is the acknowledgment that the system is operating beyond the volume it was originally designed to handle. Both things can be true at once, and understanding why helps explain why trustworthy security data is harder to produce than it might appear from the outside.

Sources

1. Inside the Advisory Database and what happens when vulnerability volume breaks records
2. Dependabot alerts – GitHub Docs
3. In GitHub’s advisory pipeline, some advisories move faster than others – Help Net Security