💻 computer science

Characterizing and Modeling the GitHub Security Advisories Review Pipeline

Dit artikel presenteert een grootschalige empirische studie van het beoordelingsproces voor GitHub Security Advisories (GHSA), waarin beoordelingspatronen en vertragingen over 288.000 adviezen worden gekarakteriseerd om onderscheidende snelle en trage verwerkingsregimes te identificeren en een wachtrijmodel wordt voorgesteld om de onderliggende mechanismen te verklaren.

Oorspronkelijke auteurs: Claudio Segal, Paulo Segal, Carlos Eduardo Banjar, Felipe de Sant'Anna Paixão, Hudson Silva Borges, Paulo Silveira, Eduardo Santana de Almeida, Joanna C. S. Santos, Anton Kocheturov, Gaurav Kumar Sriv

Gepubliceerd 2026-05-04

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Claudio Segal, Paulo Segal, Carlos Eduardo Banjar, Felipe de Sant'Anna Paixão, Hudson Silva Borges, Paulo Silveira, Eduardo Santana de Almeida, Joanna C. S. Santos, Anton Kocheturov, Gaurav Kumar Srivastava, Daniel Sadoc Menasché

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je het internet voor als een enorme, bruisende stad gebouwd door miljoenen verschillende mensen. In deze stad staan miljoenen "gebouwen" (softwareprojecten), en soms hebben deze gebouwen verborgen scheuren of kapotte sloten (beveiligingskwetsbaarheden).

Om de stad veilig te houden, is er een centraal Noodcentrum genaamd de GitHub Security Advisories (GHSA). Wanneer iemand een scheur in een gebouw ontdekt, stuurt hij een rapport naar dit centrum. De taak van het centrum is het rapport te controleren, het te stempelen als "Officieel" en vervolgens een waarschuwing uit te zenden naar iedereen in de stad, zodat ze hun sloten kunnen repareren.

Echter, dit artikel onthult een verrassend geheim over hoe dit Noodcentrum werkt: niet alle rapporten worden met dezelfde snelheid gecontroleerd, en de manier waarop je het rapport indient, telt meer dan je denkt.

Hier is het verhaal van hun bevindingen, eenvoudig uiteengezet:

1. De Twee Rijstroken

De onderzoekers keken naar meer dan 288.000 rapporten die tussen 2019 en 2025 naar het Noodcentrum werden gestuurd. Ze ontdekten dat het centrum werkt als een snelweg met twee zeer verschillende rijstroken:

De Snelle Strook (De "Lokale" Route): Als de persoon die de scheur ontdekt, de eigenaar van het gebouw is (de projectbeheerder) en hij een speciaal intern formulier gebruikt genaamd een GRA (GitHub Repository Advisory) om het te melden, wordt het rapport bijna direct gecontroleerd. Het is alsof de gebouweigenaar direct vanuit het gebouw de brandweer belt; het antwoord is direct.
De Langzame Strook (De "Externe" Route): Als het rapport uit een externe bron komt, zoals een nationale database (de NVD), moet het wachten in een lange, chaotische rij. Het is alsof een vreemde de brandweer belt via een telefooncel aan de andere kant van de stad. Zelfs nadat de gebouweigenaar de scheur al heeft gerepareerd, kan dit rapport weken of maanden in de wachtrij blijven voordat het Noodcentrum het officieel stempelt.

2. De "Snelle Strook" wordt onderbenut

Hier is de draai: Hoewel de Snelle Strook veel sneller is, maken de meeste mensen er geen gebruik van.

Ongeveer 74% van de officiële rapporten komt uit de Langzame Strook (NVD).
Slechts ongeveer 26% komt uit de Snelle Strook (GRA).

De onderzoekers ontdekten dat de Snelle Strook voornamelijk wordt gebruikt door de gebouweigenaren zelf, die vaak nieuw zijn in het systeem en dit nog nooit eerder hebben gedaan. Ondertussen wordt de Langzame Strook afgehandeld door een kleine groep zeer ervaren "inspecteurs" die duizenden rapporten hebben gecontroleerd.

3. De "Patch" versus de "Stempel"

De studie keek ook naar het tijdstip van reparaties.

In de Snelle Strook: Wanneer een gebouweigenaar een scheur repareert (een "patch" uitbrengt), gebeurt de officiële stempel (review) meestal binnen 2 dagen. De reparatie en de waarschuwing arriveren bijna tegelijkertijd.
In de Langzame Strook: Zelfs nadat de gebouweigenaar de scheur heeft gerepareerd, kan het 28 dagen (of veel langer) duren voordat de officiële stempel arriveert.

Waarom is dit belangrijk?
Stel je een inbreker (een hacker) voor die ziet dat een gebouw is gerepareerd. Als de officiële waarschuwing nog niet is gestempeld, weet de rest van de stad niet dat de reparatie bestaat. De inbreker kan nog steeds binnenbreken omdat het "Officiële Waarschuwing" nog niet is geplaatst. De Snelle Strook sluit deze kloof; de Langzame Strook laat de stad wekenlang blootgesteld.

4. Het "Wachtrij"-Model

De onderzoekers bouwden een wiskundig model (zoals een simulatie van een rij bij een koffiebar) om uit te leggen waarom dit gebeurt.

Ze ontdekten dat de Snelle Strook de "wachtzaal" volledig overslaat.
De Langzame Strook dwingt rapporten om in een "wachtzaal" (de NVD-database) te zitten voordat ze zelfs maar bij de balie kunnen komen.
Dit is niet omdat het Noodcentrum de Langzame Strook negeert; het is gewoon hoe het systeem is opgebouwd. De structuur van het proces creëert natuurlijk een vertraging voor externe rapporten.

5. Wie doet het werk?

De studie keek ook naar de betrokken personen:

De Ontdekkers: Mensen die de scheuren vinden, zijn vaak gewone mensen met een klein online volgersaantal.
De Reparaties: De mensen die daadwerkelijk de code patchen, zijn meestal de gebouweigenaren, die zeer populair en vertrouwd zijn in de gemeenschap.
De Inspecteurs: De mensen die de rapporten controleren, vormen een mix. In de Snelle Strook zijn dit vaak de gebouweigenaren zelf (die dubbel werk doen). In de Langzame Strook zijn het een gespecialiseerd team van experts die eerder honderden rapporten hebben gecontroleerd.

De Conclusie

Het artikel concludeert dat het GitHub-beveiligingssysteem een "Snelle Strook" heeft die ongelooflijk efficiënt is, maar die momenteel onderbenut wordt. De meeste rapporten nemen nog steeds de "Langzame Strook", wat een gevaarlijke vertraging creëert tussen het moment dat een reparatie klaar is en het moment dat de wereld er officieel over wordt ingelicht.

De onderzoekers suggereren dat als meer mensen worden aangemoedigd om de interne formulieren van de "Snelle Strook" (GRAs) te gebruiken in plaats van te wachten op de externe database, de hele stad veiliger zou zijn en de tijd tussen een reparatie en een waarschuwing drastisch zou krimpen. Ze hebben ook al hun data en code vrijgegeven zodat anderen deze file verder kunnen bestuderen.

1. Probleemstelling

De database voor GitHub Security Advisories (GHSA) is een kritisch onderdeel van het beheer van kwetsbaarheden in open-source software en dient als primaire bron voor tools zoals Dependabot. Het beoordelingsproces binnen GHSA is echter ondoorzichtig. Hoewel sommige adviezen een formele GitHub-beoordeling ondergaan (waarbij het rapport wordt gevalideerd en metagegevens worden verrijkt), blijft het merendeel onbeoordeeld.

Het gat: Er is een gebrek aan inzicht in de factoren die prioritering van beoordelingen sturen, de duur van beoordelingsvertragingen en of de pijplijn impliciete prioriteringsstrategieën vertoont.
De vraag: Hoe lang duren beoordelingen? Ervaren verschillende bronnen van adviezen (bijvoorbeeld GitHub Repository Advisories versus NVD-imports) verschillende beoordelingsvertragingen? Welke socio-technische factoren beïnvloeden deze uitkomsten?

2. Methodologie

De auteurs voerden een grootschalige empirische studie uit en ontwikkelden een analytisch model op basis van de volgende aanpak:

Dataset:
- Scope: 288.604 GHSA-records over de periode 2019–2025 (peildatum 21 augustus 2025).
- Focus: 23.563 door GitHub beoordeelde adviezen vormden het hoofdonderwerp van de analyse.
- Verrijking: De dataset werd verrijkt via API-query's (GitHub, NVD, deps.dev) om ontbrekende tijdstempels in te vullen (bijvoorbeeld nvd_published_at, gra_published_at, patched_at) en metagegevens over gebruikers (volgers, sterren) en repositories (OpenSSF-scores, aantal issues) te verzamelen.
Analysetechnieken:
- Statistische analyse: Gebruik van Mann-Whitney $U$ -toetsen en Rank-Biserial Correlation (RBC) om beoordelingsvertragingen te vergelijken tussen verschillende bronnen (GRA versus NVD) en gebruikersrollen.
- Stroomanalyse: Constructie van Sankey-diagrammen om de propagatie van adviezen over platforms te visualiseren (GRA $\to$ NVD $\to$ GHSA).
- Gebruikersrolanalyse: Indeling van bijdragers in 10 distincte rollen (bijvoorbeeld Analist, Rapporteur, Remediatie-ontwikkelaar) en analyse van hun specialisatie en populariteit op het platform.
- Wachtrijmodelleren: Ontwikkeling van een stochastisch wachtrijmodel ( $M/M/\infty$ en $M/M/1$ ) om de beoordelingspijplijn te simuleren en de waargenomen dichotomie in vertragingen te verklaren.

3. Belangrijkste bijdragen

Eerste grootschalige karakterisering: Een uitgebreide analyse van de frequentie, verdeling en timingdynamiek van GHSA-beoordelingen.
Ontdekking van dubbele beoordelingsregimes: Identificatie van twee distincte paden: een Snelle Weg (gedomineerd door GitHub Repository Advisories - GRAs) en een Trage Weg (gedomineerd door NVD-eerste adviezen).
Socio-technische inzichten: Analyse van gebruikersrollen die een "capaciteitspiramide" onthult, waarbij actoren voor ontdekking (vinders/rapporteurs) een lagere platformzichtbaarheid hebben dan actoren voor remediatie (ontwikkelaars/beoordelaars).
Analytisch model: Een op wachtrijen gebaseerd model dat wiskundig de vertragingverschillen verklaart op basis van pijplijnstructuur in plaats van expliciete prioritering.
Open data: Publicatie van een gecureerde dataset en scripts voor replicatie.

4. Belangrijkste resultaten

A. Gebruikersrollen en specialisatie (RQ1–RQ3)

Rollen: Het proces wordt gedomineerd door Analisten (5.610 voorkomens) en Rapporteurs (2.086). Remediatierollen (Ontwikkelaars, Beoordelaars) komen minder vaak voor maar zijn cruciaal voor latere stadia.
Specialisatie: 90% van de gebruikers specialiseert zich in precies één rol. Gebruikers met meerdere rollen combineren doorgaans rollen voor ontdekking (Vinder + Rapporteur).
Capaciteitspiramide: Er is een duidelijke correlatie tussen rol en platformprominente.
- Ontdekkingfase: Vinders en Rapporteurs hebben een laag mediaan aantal volgers (8–22) en sterren.
- Remediatiefase: Remediatie-ontwikkelaars en Beoordelaars hebben aanzienlijk hogere zichtbaarheid (mediaan 90–132 volgers, 30–59 sterren), wat suggereert dat vertrouwen en toegang vereist zijn voor codewijzigingen en beoordeling.

B. Repository-kenmerken (RQ4)

GRA versus niet-GRA: Repositories gekoppeld aan GRAs hebben significant meer kans op expliciete beveiligingsbeleid (69,3% versus 39,5%) en hogere OpenSSF "Maintained"-scores.
Ervaring van beoordelaars: GRAs worden voornamelijk beoordeeld door onervaren bijdragers (mediaan eerdere beoordelingen = 0), terwijl niet-GRA-adviezen worden afgehandeld door zeer ervaren beoordelaars (mediaan eerdere beoordelingen = 33). Dit suggereert dat GRAs vaak zelf worden beheerd door repository-beheerders.

C. Beoordelingsvertraging en bronnen (RQ5–RQ7)

Bronverdeling: Van de beoordeelde adviezen komt ongeveer 26% voort uit GRAs, terwijl ongeveer 67% uit de NVD komt.
De Snelle versus Trage Weg:
- GRAs (Snelle Weg): Mediaan tijd van publicatie tot beoordeling is 0,45 dagen (na juni 2022).
- NVD (Trage Weg): Mediaan tijd is 0,84 dagen na automatisering, maar historisch gezien veel hoger.
- Patch-naar-beoordeling-gat: Dit is de belangrijkste maatstaf. Voor GRAs is de mediaan tijd van patchpublicatie tot GHSA-beoordeling 2 dagen. Voor op NVD gebaseerde adviezen is dit 28 dagen.
Invloed van automatisering: De automatisering van NVD-imports door GitHub (aangekondigd december 2021, ingevuld juni 2022) heeft de beoordelingstijden voor NVD aanzienlijk verkort, waardoor de kloof kleiner is geworden maar het voordeel van de GRA-werkflow niet is weggenomen.

D. Modelleringresultaten

FIFO-gedrag: Het beoordelingsproces volgt grotendeels een First-In-First-Out (FIFO)-discipline, zoals blijkt uit een Longest Increasing Subsequence (LIS)-analyse.
Wachtrijmodel: De auteurs hebben het systeem gemodelleerd als:
- GRA-pad: Directe toegang tot een $M/M/1$ (single server) FIFO-wachtrij.
- NVD-pad: Toegang tot een $M/M/\infty$ (infinite server) vertragingsfase (die de NVD-buffering/verwerking voorstelt) voordat het de $M/M/1$ -beoordelingswachtrij binnenkomt.
Implicatie: Het vertragingverschil is structureel. NVD-eerste adviezen ondergaan een extra stochastische vertraging voordat ze zelfs de beoordelingswachtrij bereiken.
Wat-zij-analyse: Als 90% van de adviezen als GRAs zou ontstaan (vermindering van het NVD-gehalte $p$ van 0,47 naar 0,10), zou de gemiddelde beoordelingstijd met bijna 50% dalen (van 129 naar 66,7 dagen).

5. Betekenis en implicaties

Kwetsbaarheidsbeheer: Het "Patch-naar-beoordeling"-gat vertegenwoordigt een blootstellingsvenster waarin een oplossing bestaat, maar geautomatiseerde tools (zoals Dependabot) gebruikers nog niet kunnen waarschuwen omdat het advies nog niet is beoordeeld. De 28-daagse vertraging voor op NVD gebaseerde adviezen vergroot dit risico aanzienlijk in vergelijking met de 2-daagse vertraging voor GRAs.
Tooling en automatisering: Geautomatiseerde afhankelijkheidsbeheertools zijn afhankelijk van beoordeelde GHSAs. De bevindingen suggereren dat het aanmoedigen van beheerders om de GRA-werkflow te gebruiken (privé het maken van concept-adviezen) de beschikbaarheid van kwetsbaarheidsmetagegevens voor het ecosysteem drastisch versnelt.
Beleid: De studie benadrukt dat de huidige pijplijnstructuur inherent zelfgerapporteerde kwetsbaarheden (GRAs) bevoordeelt ten opzichte van importen uit externe databases (NVD), niet door menselijke bias, maar door pijplijntopologie.
Toekomstig werk: De auteurs roepen op tot onderzoek naar organisatorische barrières die de adoptie van de GRA-werkflow belemmeren en naar de potentie van verdere automatisering om de tijdlijnen van NVD en GHSA te synchroniseren.

Kortom, het artikel onthult dat de GitHub-beoordelingspijplijn voor beveiliging geen monolithisch proces is, maar een gebroken systeem waarbij de bron van het advies de snelheid van remediatie bepaalt. Het verschuiven van meer kwetsbaarheden naar de GRA-werkflow is de meest effectieve hefboom om de tijd tussen patchbeschikbaarheid en ecosysteem-brede bewustwording te verkorten.