arxiv: 2602.06009 · v2 · submitted 2026-02-05 · 💻 cs.CR · cs.SE

Characterizing and Modeling the GitHub Security Advisories Review Pipeline

Claudio Segal , Paulo Segal , Carlos Eduardo Banjar , Felipe de Sant'Anna Paix\~ao , Hudson Silva Borges , Paulo Silveira , Eduardo Santana de Almeida , Joanna C. S. Santos

show 3 more authors

Anton Kocheturov Gaurav Kumar Srivastava Daniel Sadoc Menasch\'e

This is my paper

Pith reviewed 2026-05-16 06:30 UTC · model grok-4.3

classification 💻 cs.CR cs.SE

keywords GitHub Security Advisoriesreview latencyqueueing modelvulnerability disclosureNVDopen-source securityGHSAempirical study

0 comments p. Extension

The pith

GitHub Security Advisories follow one of two review-latency regimes depending on whether they originate from GitHub repositories or the NVD.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper examines over 288,000 GitHub Security Advisories from 2019 to 2025 to map which ones receive review and how long the process takes. It finds that the pipeline operates in two regimes: a fast path dominated by GitHub Repository Advisories and a slow path dominated by those that first appear in the National Vulnerability Database. A queueing model built around the structure of the advisory intake points accounts for the observed differences in delay. This matters because GHSA records drive security tools and developer awareness, so knowing the review timelines helps predict when a vulnerability becomes reliably public.

Core claim

We identify two distinct review-latency regimes: a fast path dominated by GitHub Repository Advisories (GRAs) and a slow path dominated by NVD-first advisories. We further develop a queueing model that accounts for this dichotomy based on the structure of the advisory processing pipeline.

What carries the argument

A queueing model that separates the advisory review pipeline into fast and slow paths according to the advisory's entry point.

If this is right

Advisories entering via GitHub Repository Advisories receive faster review than those that first appear via NVD.
Overall review times shift predictably when the relative volume of GRAs versus NVD-first submissions changes.
The probability that an advisory receives review correlates with its origin in the disclosure pipeline.
A basic queueing model with two service classes reproduces the empirical latency distributions.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Security monitoring tools could estimate review completion time from an advisory's reported origin and adjust alert priorities accordingly.
Vulnerability reporters might reduce public disclosure lag by submitting directly through GitHub rather than waiting for NVD publication.
The same two-path structure may appear in other vulnerability platforms that accept intake from multiple external sources.
If GitHub alters its intake rules, the queueing model would need re-parameterization to remain predictive.

Load-bearing premise

The observed latency differences arise primarily from the two distinct entry points into the review pipeline, and a standard queueing model with parameters estimated from the data accurately captures the process without unmodeled policy changes.

What would settle it

A new collection of post-2025 advisories in which NVD-first entries show review times statistically indistinguishable from GRAs, or in which the fitted queueing model produces large prediction errors on fresh data.

Figures

Figures reproduced from arXiv: 2602.06009 by Anton Kocheturov, Carlos Eduardo Banjar, Claudio Segal, Daniel Sadoc Menasch\'e, Eduardo Santana de Almeida, Felipe de Sant'Anna Paix\~ao, Gaurav Kumar Srivastava, Hudson Silva Borges, Joanna C. S. Santos, Paulo Segal, Paulo Silveira.

**Figure 2.** Figure 2: Reviewer experience at review time (ECDF) for GRA [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** Figure 3: Reviews per month by source Key finding 1 for RQ5. GRAs constitute a stable and persistent source of GHSAs, accounting for roughly one-quarter all reviewed advisories. 5.2.2 Flow of Advisories. The advisory flow, i.e. the sequence in which advisories appear across platforms, can be represented as a Sankey diagram ( [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

**Figure 4.** Figure 4: Flow of reviewed GHSA across platforms. For each advisory, we consider the sequence of platforms that published it, sorted by publish date. From the sequence, we determine tuples (𝑥, 𝑦) where 𝑥 and 𝑦 are platforms with distinct consecutive publish dates. The Sankey diagram is generated from the multiset S of all such tuples, constructed as follows. If platforms 𝑥, 𝑦 and 𝑧 publish the same advisory on thre… view at source ↗

**Figure 5.** Figure 5: Median review time by publish month by source [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗

**Figure 6.** Figure 6: Advisory review and publication order: (a) raw data (10,532 advisories); (b) data after Jun 2022 (4,404); (c) model results. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗

**Figure 7.** Figure 7: Modeling the review process: (a) detailed and (b) [PITH_FULL_IMAGE:figures/full_fig_p009_7.png] view at source ↗

read the original abstract

GitHub Security Advisories (GHSA) have become a central component of open-source vulnerability disclosure and are widely used by developers and security tools. A distinctive feature of GHSA is that only a fraction of advisories are reviewed by GitHub, while the mechanisms associated with this review process remain poorly understood. In this paper, we conduct a large-scale empirical study of the GHSA review processes, analyzing over 288,000 advisories spanning 2019-2025. We characterize which advisories are more likely to be reviewed, quantify review delays, and identify two distinct review-latency regimes: a fast path dominated by GitHub Repository Advisories (GRAs) and a slow path dominated by NVD-first advisories. We further develop a queueing model that accounts for this dichotomy based on the structure of the advisory processing pipeline.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

The paper maps GHSA review times into fast GRA and slow NVD-first regimes and fits a queueing model to the split, but the model may average over policy shifts across 2019-2025.

read the letter

The main point is that GHSA review shows two clear latency regimes driven by entry point—fast for GitHub Repository Advisories and slow for NVD-first ones—and the authors fit a queueing model to that structure on 288k advisories from 2019-2025. The scale of the characterization is the real strength here. They quantify review likelihood and delays in a way that lines up with how the pipeline actually routes items, and the two-regime split plus the model give a practical handle on what affects turnaround times. That part is new and directly useful for anyone building security tooling or studying disclosure processes. The queueing approach is a natural fit for the entry-point dichotomy they describe. The soft spot is the stationarity assumption. GitHub changed triage rules, automation, and priorities several times in that window, so the fitted rates could be an average across non-stationary periods rather than a stable structural feature. Without time-series splits or checks for policy breakpoints in the methods, it's unclear how much the model explains versus just describes the aggregate data. The abstract leaves the statistical tests, validation, and data cleaning details opaque, which is why soundness is hard to judge from what we have. This is for researchers and practitioners working on open-source supply chain security or vulnerability disclosure pipelines. A reader who needs empirical baselines on GHSA behavior will find the dataset size and regime split worth the time. It deserves peer review because the question is relevant and the data volume is substantial, even if the model needs robustness work on temporal stability.

Referee Report

1 major / 2 minor

Summary. The paper conducts a large-scale empirical study of over 288,000 GitHub Security Advisories (GHSA) spanning 2019-2025. It characterizes which advisories are more likely to be reviewed, quantifies review delays, identifies two distinct review-latency regimes (a fast path dominated by GitHub Repository Advisories and a slow path dominated by NVD-first advisories), and develops a queueing model to account for this dichotomy based on the structure of the advisory processing pipeline.

Significance. If the results hold, the work is significant for open-source security research because it provides the first detailed empirical characterization of the GHSA review process, which is widely used but poorly understood. The large dataset enables robust identification of latency regimes, and the queueing model supplies a structural explanation that could guide improvements in vulnerability disclosure pipelines. The empirical scale and modeling attempt are clear strengths.

major comments (1)

[§5 (Queueing Model)] §5 (Queueing Model): The model treats the review pipeline as a stationary two-path system with fixed arrival and service rates estimated from the full 2019-2025 corpus. Given documented changes in GitHub's triage policies and automation during this interval, the fitted parameters may reflect an average over non-stationary regimes rather than a stable structural feature. Time-split validation or explicit checks for regime shifts are required to confirm that the two-entry-point structure explains the observed dichotomy.

minor comments (2)

[Introduction and §3 (Data)] Introduction and §3 (Data): The exact total count after filtering, the precise definition of 'reviewed' vs. unreviewed advisories, and any temporal coverage gaps should be stated explicitly to support reproducibility.
[Figures 4-6] Figures 4-6: Axis labels and legend entries for latency distributions should include units (e.g., days) and confidence intervals to improve clarity.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for their constructive feedback on the stationarity assumptions underlying our queueing model. We address the concern directly below by incorporating the requested validation.

read point-by-point responses

Referee: The model treats the review pipeline as a stationary two-path system with fixed arrival and service rates estimated from the full 2019-2025 corpus. Given documented changes in GitHub's triage policies and automation during this interval, the fitted parameters may reflect an average over non-stationary regimes rather than a stable structural feature. Time-split validation or explicit checks for regime shifts are required to confirm that the two-entry-point structure explains the observed dichotomy.

Authors: We agree that the multi-year span introduces a legitimate risk of non-stationarity. In the revised manuscript we have added an explicit time-split validation: the corpus is partitioned into 2019-2021 and 2022-2025 sub-periods (chosen to bracket documented GitHub automation changes), arrival and service rates are re-estimated independently for each window, and the two-path model is re-fitted. The structural dichotomy persists in both windows with qualitatively similar parameter values and explanatory power for the fast/slow latency regimes. These results, together with a brief discussion of policy evolution, have been incorporated into an expanded Section 5 and a new appendix. revision: yes

Circularity Check

0 steps flagged

No significant circularity in empirical characterization or queueing model

full rationale

The paper performs a large-scale empirical study of 288,000+ GHSA records from 2019-2025, directly observes the fast/slow latency regimes from the data, and fits a queueing model whose parameters are estimated from the same observations to account for the observed pipeline structure. No equations or claims reduce the identified regimes or delays to fitted quantities by construction, no self-definitional loops exist, and no load-bearing self-citations or smuggled ansatzes are present. The derivation remains self-contained against the external dataset benchmarks.

Axiom & Free-Parameter Ledger

1 free parameters · 1 axioms · 0 invented entities

The queueing model rests on standard queueing-theory assumptions (Poisson arrivals, exponential service times) and parameters (arrival and service rates per regime) estimated from the advisory data; no new physical entities are postulated.

free parameters (1)

arrival and service rates for fast and slow paths
Estimated from the 288k advisory dataset to parameterize the two-regime queueing model.

axioms (1)

domain assumption Review process can be modeled as two independent queues with standard queueing assumptions
Invoked to justify the queueing model that accounts for the observed latency dichotomy.

pith-pipeline@v0.9.0 · 5490 in / 1281 out tokens · 49764 ms · 2026-05-16T06:30:11.958560+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

49 extracted references · 49 canonical work pages

[1]

Abduljaleel Al-Rubaye and Gita Sukthankar. 2020. Scoring Popularity in GitHub. In2020 International Conference on Computational Science and Computational Intelligence (CSCI). IEEE, Las Vegas, NV, USA, 222–227. doi:10.1109/CSCI51800. 2020.00044

work page doi:10.1109/csci51800 2020
[2]

Nikolaos Alexopoulos, Andrew Meneely, Dorian Arnouts, and Max Mühlhäuser

work page
[3]

In Proceedings of the 15th ACM/IEEE international symposium on empirical software engineering and measurement (ESEM)

Who are vulnerability reporters? A large-scale empirical study on FLOSS. In Proceedings of the 15th ACM/IEEE international symposium on empirical software engineering and measurement (ESEM). 1–12

work page
[4]

Luca Allodi, Marco Cremonini, Fabio Massacci, and Woohyun Shim. 2020. Mea- suring the accuracy of software vulnerability assessments: experiments with students and professionals.Empirical Software Engineering25, 2 (2020), 1063– 1094

work page 2020
[5]

Luca Allodi and Fabio Massacci. 2017. Security events and vulnerability data for cybersecurity risk estimation.Risk Analysis37, 8 (2017), 1606–1627

work page 2017
[6]

Ashish Arora, Ramayya Krishnan, Rahul Telang, and Yubao Yang. 2010. An empir- ical analysis of software vendors’ patch release behavior: impact of vulnerability disclosure.Information Systems Research21, 1 (2010), 115–132

work page 2010
[7]

Jessy Ayala, Steven Ngo, and Joshua Garcia. 2025. A deep dive into how open- source project maintainers review and resolve bug bounty reports. In2025 IEEE Symposium on Security and Privacy (SP). IEEE, 522–538

work page 2025
[8]

Jessy Ayala, Yu-Jye Tung, and Joshua Garcia. 2024. Poster: A glimpse of vulnera- bility disclosure behaviors and practices using GitHub projects. InProceedings of the 45th IEEE Symposium on Security and Privacy (S&P)

work page 2024
[9]

Jessy Ayala, Yu-Jye Tung, and Joshua Garcia. 2025. A Mixed-Methods Study of Open-Source Software Maintainers On Vulnerability Management and Platform Security Features. In34th USENIX Security Symposium (USENIX Security 25). 2105–2124

work page 2025
[10]

Jessy Ayala, Yu-Jye Tung, and Joshua Garcia. 2025. Investigating Vulnerability Disclosures in Open-Source Software Using Bug Bounty Reports and Security Advisories.arXiv preprint arXiv:2501.17748(2025)

work page arXiv 2025
[11]

Hudson Borges and Marco Tulio Valente. 2018. What’s in a GitHub star? un- derstanding repository starring practices in a social coding platform.Journal of Systems and Software146 (2018), 112–129

work page 2018
[12]

Mehran Bozorgi, Lawrence K Saul, Stefan Savage, and Geoffrey M Voelker. 2010. Beyond heuristics: learning to classify vulnerabilities and predict exploits. In Proceedings of the 16th ACM SIGKDD international conference on Knowledge discovery and data mining. 105–114

work page 2010
[13]

Valerio Cosentino, Javier L Cánovas Izquierdo, and Jordi Cabot. 2017. A systematic mapping study of software development with GitHub.Ieee access5 (2017), 7173– 7192

work page 2017
[14]

Alexandre Decan, Tom Mens, and Eleni Constantinou. 2018. On the impact of security vulnerabilities in the npm package dependency network. InProceedings of the 15th international conference on mining software repositories. 181–191

work page 2018
[15]

Jonathan Evans. 2025. GitHub Advisory Database by the numbers: Known security vulnerabilities and what you can do about them. https://github.blog/security/github-advisory-database-by-the-numbers- known-security-vulnerabilities-and-what-you-can-do-about-them/ Accessed: 2025-09-30

work page 2025
[16]

Michael Gegick, Pete Rotella, and Tao Xie. 2010. Identifying security bug reports via text mining: An industrial case study. In2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010). IEEE, 11–20

work page 2010
[17]

GitHub. 2025. GitHub Advisory Database: Security vulnerability database inclusive of CVEs and GitHub-originated security advisories. https:// github.com/advisories See also https://github.com/github/advisory-database and https://docs.github.com/en/code-security/security-advisories/working-with- MSR ’26, April 13–14, 2026, Rio de Janeiro, Brazil Claudio Se...

work page 2025
[18]

GitHub Blog. 2021. Advisory Database now includes an Unreviewed Advi- sories section. https://github.blog/changelog/2021-12-16-advisory-database- now-includes-an-unreviewed-advisories-section/ Accessed: 2025-09-12

work page 2021
[19]

GitHub Blog. 2022. All historical NVD advisories are now listed on GitHub. https://github.blog/changelog/2022-06-08-all-historical-nvd-advisories- are-now-listed-on-github/ Accessed: 2025-09-12

work page 2022
[20]

GitHub Blog. 2023. Security advisories now have multiple types of cred- its. https://github.blog/changelog/2023-03-07-security-advisories-now-have- multiple-types-of-credits/ Accessed: 2025-10-16

work page 2023
[21]

GitHub Docs. 2025. About credits for repository security advisories. https://docs.github.com/en/code-security/security-advisories/working-with- repository-security-advisories/creating-a-repository-security-advisory#about- credits-for-repository-security-advisories Accessed: 2025-10-20

work page 2025
[22]

GitHub Docs. 2025. About Dependabot alerts. https://docs.github.com/ en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts Ac- cessed: 2025-10-16

work page 2025
[23]

GitHub Docs. 2025. About the GitHub Advisory Database. https: //docs.github.com/en/code-security/security-advisories/working-with- global-security-advisories-from-the-github-advisory-database/about-the- github-advisory-database Accessed: 2025-10-16

work page 2025
[24]

GitHub Docs. 2025. REST API endpoints for global security advi- sories. https://docs.github.com/en/rest/security-advisories/global-advisories? apiVersion=2022-11-28#list-global-security-advisories Acessed: 2025-08-29

work page 2025
[25]

2013.Performance modeling and design of computer systems: queueing theory in action

Mor Harchol-Balter. 2013.Performance modeling and design of computer systems: queueing theory in action. Cambridge University Press

work page 2013
[26]

Runzhi He, Hao He, Yuxia Zhang, and Minghui Zhou. 2023. Automating depen- dency updates in practice: An exploratory study on GitHub Dependabot.IEEE Transactions on Software Engineering49, 8 (2023), 4004–4022

work page 2023
[27]

Sushawapak Kancharoendee, Thanat Phichitphanphong, Chanikarn Jongy- ingyos, Brittany Reid, Raula Gaikovina Kula, Morakot Choetkiertikul, Chaiyong Ragkhitwetsagul, and Thanwadee Sunetnanta. 2025. On Categorizing Open Source Software Security Vulnerability Reporting Mechanisms on GitHub. In 2025 IEEE International Conference on Software Analysis, Evolution ...

work page 2025
[28]

Timothy Kinsman, Mairieli Wessel, Marco A Gerosa, and Christoph Treude. 2021. How do software developers use github actions to automate their workflows?. In2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). IEEE, 420–431

work page 2021
[29]

Frank Li and Vern Paxson. 2017. A large-scale empirical study of security patches. InProceedings of the 2017 ACM SIGSAC Conference on Computer and Communica- tions Security. 2201–2215

work page 2017
[30]

Shuhan Liu, Jiayuan Zhou, Xing Hu, Filipe Roseiro Cogo, Xin Xia, and Xiaohu Yang. 2025. An empirical study on vulnerability disclosure management of open source software systems.ACM Transactions on Software Engineering and Methodology(2025)

work page 2025
[31]

B. F. Logan and L. A. Shepp. 1977. A variational problem for random Young tableaux.Advances in Mathematics26, 2 (1977), 206–222. doi:10.1016/0001- 8708(77)90030-5

work page doi:10.1016/0001- 1977
[32]

Lucas Miranda, Daniel Vieira, Leandro Aguiar, Daniel Menasché, Miguel Angelo Bicudo, Mateus Nogueira, Matheus Martins, Leonardo Ventura, Lucas Senos, and Enrico Lovat. 2021. On the Flow of Software Security Advisories.IEEE Transactions on Network and Service ManagementPP (05 2021), 1–1. doi:10.1109/ TNSM.2021.3078727

work page arXiv 2021
[33]

Samim Mirhosseini and Chris Parnin. 2017. Can automated pull requests en- courage software developers to upgrade out-of-date dependencies?. In2017 32nd IEEE/ACM international conference on automated software engineering (ASE). IEEE, 84–94

work page 2017
[34]

MITRE Corporation. 2023. CNA Rules and CVE Program Governance. https: //www.cve.org/resourcessupport/allresources/cnarules. Accessed: 2025-10-23

work page 2023
[35]

Antonio Nappa, Richard Johnson, Leyla Bilge, Juan Caballero, and Tudor Dumi- tras. 2015. The attack of the clones: A study of the impact of shared code on vulnerability patching. In2015 IEEE symposium on security and privacy. IEEE, 692–708

work page 2015
[36]

NIST. 2025. NVD - Home. https://nvd.nist.gov/. [Accessed 23-10-2025]

work page 2025
[37]

OSSF. 2025. OpenSSF Scorecard Checks. https://github.com/ossf/scorecard/blob/ main/docs/checks.md Accessed: 2025-10-19

work page 2025
[38]

Donald Pinckney, Federico Cassano, Arjun Guha, and Jonathan Bell. 2023. A large scale analysis of semantic versioning in npm. In2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR). IEEE, 485–497

work page 2023
[39]

Serena Elisa Ponta, Henrik Plate, and Antonino Sabetta. 2020. Detection, assess- ment and mitigation of vulnerabilities in open source dependencies.Empirical Software Engineering25, 5 (2020), 3175–3215

work page 2020
[40]

Piotr Przymus, Mikołaj Fejzer, Jakub Narębski, and Krzysztof Stencel. 2023. The secret life of CVEs. In2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR). IEEE, 362–366

work page 2023
[41]

Schorlemmer, Kelechi G

Taylor R. Schorlemmer, Kelechi G. Kalu, Luke Chigges, Kyung Myung Ko, Eman Abu Ishgair, Saurabh Baghi, Santiago Torres-Arias, and James C. Davis

work page
[42]

InIEEE Symposium on Security and Privacy, SP 2024, San Francisco, CA, USA, May 19-23, 2024

Signing in Four Public Software Package Registries: Quantity, Quality, and Influencing Factors. InProceedings of the 45th IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, Los Alamitos, CA, USA, 1160–1178. doi:10.1109/SP54263.2024.00215

work page doi:10.1109/sp54263.2024.00215 2024
[43]

Rahul Telang and Sunil Wattal. 2007. An empirical analysis of the impact of software vulnerability announcements on firm stock price.IEEE Transactions on Software engineering33, 8 (2007), 544–557

work page 2007
[44]

Saad Ullah, Praneeth Balasubramanian, Wenbo Guo, Amanda Burnett, Hammond Pearce, Christopher Kruegel, Giovanni Vigna, and Gianluca Stringhini. 2025. From CVE Entries to Verifiable Exploits: An Automated Multi-Agent Framework for Reproducing CVEs.arXiv preprint arXiv:2509.01835(2025)

work page arXiv 2025
[45]

A. M. Vershik and S. V. Kerov. 1977. Asymptotics of the Plancherel measure of the symmetric group and the limit form of Young tableaux.Soviet Mathematics Doklady18 (1977), 527–531

work page 1977
[46]

Brandon Wang, Xiaoye Li, Leandro P de Aguiar, Daniel S Menasche, and Zubair Shafiq. 2017. Characterizing and modeling patching practices of industrial control systems.Proceedings of the ACM on Measurement and Analysis of Computing Systems1, 1 (2017), 1–23

work page 2017
[47]

H. W. Wendt. 1972. Dealing with a common problem in Social Science: A simpli- fied rank-biserial coefficient of correlation based on the 𝑈 statistic.European Journal of Social Psychology2, 4 (1972), 463–465. doi:10.1002/ejsp.2420020412

work page doi:10.1002/ejsp.2420020412 1972
[48]

Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel

work page
[49]

In28th USENIX Security symposium (USENIX security 19)

Small world with high risks: A study of security threats in the npm ecosystem. In28th USENIX Security symposium (USENIX security 19). 995–1010

work page