SECOND MEASUREMENT SM-021

Dependabot doesn’t alert on a security advisory until GitHub reviews it, which GitHub’s documentation says “can take up to 72 hours”. Since April, 3,226 of 4,472 reviewed advisories took longer, and the median wait was 8 days

Markovian ProtocolMeasured 2026-10-17Status: published 2026-10-19; questions sent to GitHub 2026-10-19DOI: 10.5281/zenodo.23439042

The claim: GitHub advisory review: docs say up to 72 hours; since April, 72.1% of reviewed advisories took longer

What we found: 3,226 of 4,472 advisories published since April took longer than 72 hours to be reviewed (72.1%), median 8 days; January to March, 4.6%. Dependabot does not alert until review.

Status: Published 19 Oct; question to the GitHub Advisory Database team pending

When a project publishes a security advisory on GitHub, GitHub reviews it into the GitHub Advisory Database, and Dependabot does not alert on an advisory until it is reviewed. GitHub’s documentation says the review “can take up to 72 hours”. We read both timestamps for every CVE GitHub issued that NVD published from 1 January to 16 October 2026; 7,076 have a 2026 advisory naming a package in an ecosystem the database supports. Of those reviewed, 4.6% of January to March advisories took longer than 72 hours; from April on, 72.1%.

The short version

GitHub’s documentation on repository security advisories: “GitHub will review each published security advisory, add it to the GitHub Advisory Database, and may use the security advisory to send Dependabot alerts to affected repositories. … This process can take up to 72 hours” (read 2026-10-17).¹ And on the database: “Dependabot doesn’t create Dependabot alerts for unreviewed advisories”.³
Two public timestamps per advisory: when the project published it (the repository advisory’s published_at) and when GitHub reviewed it into the database (github_reviewed_at). We read both for every CVE GitHub issued that NVD published from 1 January to 16 October 2026: 11,848 CVEs, of which 7,076 have a 2026 advisory naming a package in a supported ecosystem.
January to March: 69 of 1,514 reviewed advisories took longer than 72 hours (4.6%), median 20 hours.
April to 16 October: 3,226 of 4,472 (72.1%), median 8 days among those reviewed. Another 846 from those months were not in the database when we read it, every one already older than 72 hours. Not all of them are waiting: from January to March, when reviews were fast, 244 of 1,758 advisories (13.9%) were never reviewed and are now at least 199 days old, so many of the 846 are probably declined rather than queued. The longest wait for an April-onward advisory that was reviewed: lucasdillmann/nginx-ignition (GHSA-jr34-h97m-9hpx), 119 days.
The longest reviewed waits of the year were for advisories published in February and March and reviewed in July and September: lucasdillmann/nginx-ignition (GHSA-hf33-q6cf-c66f), 178 days; bigcat88/pillow_heif (GHSA-5gjj-6r7v-ph3x), 143 days; and two open-webui/open-webui advisories published the same day, GHSA-vjm7-m4xh-7wrc and GHSA-xc8p-9rr6-97r2, 140 days each.
GitHub has said it is behind. Its blog, 29 June: “Since mid-April, due to this surge, we have not consistently met our internal goals for publication. Processing times extended first to about a week, then to multiple weeks for a meaningful share.”² On 8 September a GitHub staff member wrote, of CVE publication requests, “we’re currently processing records in the order they’re received, with a turnaround of approximately five weeks.”⁴ That reply is about the CVE-request queue, for which the same documentation says “GitHub usually reviews the request within 72 hours.”¹
A second path, the database’s own git history: for 40 randomly chosen reviewed 2026 advisories (36 of them in the counted set), the file first appears under github-reviewed/ 0.7 to 16.3 minutes after the reviewed time the API gives (git_check_2026-10-17.json). This confirms the end of each wait; the start, published_at, rests on the repository advisory API alone.

Disclosure: Markovian Protocol holds no financial position in GitHub or Microsoft, was paid by no one for this work, and showed it to no one before publication. How we work.

Month by month

Advisory published	In sample	Reviewed	Over 72 h	Share	Median wait, reviewed	Median if all not in database are waiting	Not in database	Days to NVD (median)
January 2026	311	274	12	4.4%	11 hours	14 hours	37	0.5
February 2026	438	381	18	4.7%	15 hours	19 hours	57	1
March 2026	1,009	859	39	4.5%	24 hours	30 hours	150	1.8
April 2026	1,022	856	309	36.1%	34 hours	53 hours	166	4.6
May 2026	1,202	1,051	805	76.6%	6 days	7 days	151	24.4
June 2026	1,357	1,155	881	76.3%	23 days	36 days	202	34
July 2026	912	704	593	84.2%	31 days	51 days	208	27.5
August 2026 †	435	351	309	88.0%	27 days	38 days	84	20.2
September 2026 †	351	318	303	95.3%	14 days	15 days	33	13.8
October 2026 †	39	37	26	70.3%	6 days	6 days	2	4.3

Repository advisories behind CVEs issued by GitHub (NVD source identifier security-advisories@github.com) and published by NVD 1 January to 16 October 2026, whose advisory names a package in npm, pip, Maven, NuGet, Go, RubyGems, Composer, Rust, Erlang, Actions, Pub or Swift, the ecosystems the database supports.³ Wait = github_reviewed_at minus the repository advisory’s published_at, compared to the second. The second median counts each advisory not in the database at its age when we read it. It is a floor only if every one of them is still waiting; some were probably declined (see the short version), and those pull it up. Read from 11:55 UTC on 2026-10-17.

Why the recent months look better than they are (†). The sample is chosen by the date NVD published the CVE, and GitHub usually reviews the advisory before its CVE appears on NVD: 4,100 of the 5,986 reviewed advisories. As the queue grew, the gap from a project’s advisory to its CVE on NVD grew too, to a median of 34 days for June’s advisories. So an advisory published in August, September or October that is still waiting mostly has no CVE on NVD yet and is not in our sample at all. That makes the counts for those months too low and their medians too short, so the falling medians after July cannot be read as a recovery.

By ecosystem

Ecosystem	Reviewed in 2026	Over 72 h	Median wait
npm	1,826	54.2%	4 days
pip	1,332	59.5%	6 days
go	1,222	54.3%	91 hours
composer	807	49.8%	71 hours
maven	348	64.9%	7 days
rust	197	51.8%	73 hours
rubygems	159	43.4%	39 hours
nuget	123	70.7%	8 days

Every ecosystem with 100 or more reviewed advisories, by the ecosystems the project named in its own advisory; one naming packages in two ecosystems counts in both. 766 reviewed advisories whose project left the ecosystem blank or unsupported, but which GitHub reviewed into a supported one, are not counted. Adding them changes little: 5.1% over 72 hours for January to March, 71.8% from April.

Why the wait matters

A project that publishes an advisory has already told the world about the flaw. The projects that depend on it hear from Dependabot, and Dependabot does not alert on an unreviewed advisory.³ GitHub’s blog said so for the backlog: “New advisories may take longer to trigger, with critical issues prioritized.”² Our numbers do not separate advisories by severity, so critical ones may move faster than the median. For the median advisory published since April that has been reviewed, the gap was 8 days.

A study of 2019 to 2025 found repository advisories were the database’s fast path.⁵ Our January to March numbers agree; the change starts in April.

How this ends

GitHub can close it either way: by clearing the queue until reviews are back inside 72 hours, or by changing the documentation to say what to expect now. The blog promised, “If things improve, we’ll tell you,” and the September staff reply, about CVE request turnaround, said “Feedback around updating our turnaround time was passed along to our curation team.”⁴ We recheck monthly and print the table here.

Our questions to the GitHub Advisory Database team

Will the documentation’s “up to 72 hours” be updated to the current expectation, and is there a date by which reviews will be back inside it?
Would you publish the queue: advisories waiting and the median wait, weekly?
Of the 1,090 2026 advisories in our sample that were not in the database on 2026-10-17, how many were declined and how many are still waiting?

Their reply, scored

Sent 19 October as issue 10425; no reply yet.

What we told whom, and when.

17 Oct 2026	Measured. Nobody has seen the page.
19 Oct 2026	Published. The three questions above opened as github/advisory-database issue 10425, where the curation team answers in public.

What we can’t be sure of

The sample is chosen by NVD publication date, which leaves out recent advisories still waiting (see the † note); the shares and medians for August to October are too low.
Advisories not in the database are left out of the shares because some may have been declined; from January to March, 13.9% were never reviewed. Those still waiting would make the real shares and medians higher. The month table’s second median counts all of them as waiting.
We take the repository advisory’s published_at as the moment the advisory became public. For five CVEs NVD’s date is 8 to 65 days earlier, probably because the advisory was republished; one of them, steveukx/git-js (GHSA-r275-fr43-pm7q), is in the counted set with a negative wait and is left out.
Only CVEs GitHub issued are counted. Left out: 143 with no advisory link in NVD, 27 whose repository advisory we could not read, 14 with an advisory published before 2026, 4,587 naming no supported ecosystem, and the one with a negative wait above.
Severity is not separated; GitHub says critical issues are prioritized.

Run it yourself

gunzip -k exhibits/census_2026-10-17.jsonl.gz
python3 analyze.py exhibits/census_2026-10-17.jsonl 2026-10-17T11:55:00Z summary_2026-10-17.json
python3 git_check.py exhibits/census_2026-10-17.jsonl 40 20261017 git_check_2026-10-17.json
python3 ghsa_census.py census_new.jsonl 2026-01-01 2026-10-16   # a fresh census, about four hours

Needs Python 3 and the GitHub CLI logged in; NVD’s API is anonymous and paced. The census makes about 24,000 GitHub API calls, roughly four hours at the standard rate limit. Scripts and exhibits: sm-021/.

References

GitHub Docs, Repository security advisories. docs.github.com, saved copy github_docs_about_repository_security_advisories_2026-10-17.md.
GitHub Blog, Inside the Advisory Database and what happens when vulnerability volume breaks records, 29 June 2026, updated 1 July. github.blog, saved copy github_blog_2026-06-29_advisory_database_volume.html.
GitHub Docs, GitHub Advisory database. docs.github.com, saved copy github_docs_about_the_github_advisory_database_2026-10-17.md.
GitHub Community discussion 205706, CVE not assigned for 24 days?, staff reply of 8 September 2026. github.com, saved copy github_community_discussion_205706_2026-10-17.json; the replier’s GitHub profile (company “GitHub”), github_user_ghostinhershell_2026-10-18.json.
C. Segal, P. Segal, C. E. Banjar et al., Characterizing and Modeling the GitHub Security Advisories Review Pipeline, MSR 2026. arXiv:2602.06009.
NVD CVE API 2.0, sourceIdentifier=security-advisories@github.com; GitHub REST API, repository security advisories and global advisories; github/advisory-database commit history.