Characterizing and Modeling the GitHub Security Advisories Review Pipeline
Dieser Beitrag stellt eine groß angelegte empirische Untersuchung des Review-Prozesses für GitHub-Sicherheitsmitteilungen (GHSA) vor, die Review-Muster und -Verzögerungen über 288.000 Mitteilungen hinweg charakterisiert, um unterschiedliche schnelle und langsame Verarbeitungsregime zu identifizieren, und schlägt ein Warteschlangenmodell vor, um die zugrundeliegenden Mechanismen zu erklären.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich das Internet als eine massive, geschäftige Stadt vor, die von Millionen verschiedener Menschen erbaut wurde. In dieser Stadt gibt es Millionen von „Gebäuden" (Softwareprojekte), und manchmal weisen diese Gebäude verborgene Risse oder defekte Schlösser (Sicherheitslücken) auf.
Um die Stadt sicher zu halten, gibt es ein zentrales Notfall-Einsatzleitungs-Zentrum namens GitHub Security Advisories (GHSA). Wenn jemand einen Riss in einem Gebäude entdeckt, sendet er einen Bericht an dieses Zentrum. Die Aufgabe des Zentrums besteht darin, den Bericht zu prüfen, mit dem Stempel „Offiziell" zu versehen und dann eine Warnung an alle in der Stadt zu senden, damit sie ihre Schlösser reparieren können.
Dieses Papier enthüllt jedoch ein überraschendes Geheimnis darüber, wie dieses Einsatzleitungs-Zentrum funktioniert: Nicht alle Berichte werden mit derselben Geschwindigkeit geprüft, und die Art und Weise, wie Sie den Bericht senden, ist wichtiger, als Sie denken.
Hier ist die Geschichte ihrer Erkenntnisse, einfach aufgeschlüsselt:
1. Die zwei Fahrspuren des Verkehrs
Die Forscher untersuchten über 288.000 Berichte, die zwischen 2019 und 2025 an das Einsatzleitungs-Zentrum gesendet wurden. Sie stellten fest, dass das Zentrum wie eine Autobahn mit zwei sehr unterschiedlichen Spuren funktioniert:
- Die Schnellspur (Die „lokale" Route): Wenn die Person, die den Riss entdeckt hat, der Eigentümer des Gebäudes (der Projektbetreuer) ist und sie ein spezielles internes Formular namens GRA (GitHub Repository Advisory) verwendet, um ihn zu melden, wird der Bericht fast sofort geprüft. Es ist, als würde ein Gebäudeeigentümer die Feuerwehr direkt von innerhalb des Gebäudes rufen; die Reaktion ist sofortig.
- Die Langsamspur (Die „externe" Route): Wenn der Bericht von einer externen Quelle stammt, wie etwa einer nationalen Datenbank (der NVD), muss er in einer langen, chaotischen Schlange warten. Es ist, als würde ein Fremder die Feuerwehr von einem Münztelefon quer durch die Stadt anrufen. Selbst nachdem der Gebäudeeigentümer den Riss bereits repariert hat, kann dieser Bericht wochen- oder monatelang in der Warteschlange liegen, bevor das Einsatzleitungs-Zentrum ihn offiziell stempelt.
2. Die „Schnellspur" wird untergenutzt
Hier kommt die Wendung: Obwohl die Schnellspur viel schneller ist, nutzen die meisten Menschen sie nicht.
- Etwa 74 % der offiziellen Berichte stammen aus der Langsamspur (NVD).
- Nur etwa 26 % stammen aus der Schnellspur (GRA).
Die Forscher stellten fest, dass die Schnellspur hauptsächlich von den Gebäudeeigentümern selbst genutzt wird, die oft neu im System sind und dies noch nie zuvor getan haben. Unterdessen wird die Langsamspur von einer kleinen Gruppe sehr erfahrener „Inspektoren" bearbeitet, die Tausende von Berichten geprüft haben.
3. Der „Patch" versus der „Stempel"
Die Studie untersuchte auch den Zeitpunkt der Reparaturen.
- In der Schnellspur: Wenn ein Gebäudeeigentümer einen Riss repariert (ein „Patch" veröffentlicht), erfolgt der offizielle Stempel (Prüfung) normalerweise innerhalb von 2 Tagen. Die Reparatur und die Warnung kommen fast gleichzeitig an.
- In der Langsamspur: Selbst nachdem der Gebäudeeigentümer den Riss repariert hat, kann es 28 Tage (oder viel länger) dauern, bis der offizielle Stempel eintrifft.
Warum ist das wichtig?
Stellen Sie sich einen Einbrecher (einen Hacker) vor, der sieht, dass ein Gebäude repariert wurde. Wenn die offizielle Warnung noch nicht gestempelt wurde, weiß der Rest der Stadt nicht, dass die Reparatur existiert. Der Einbrecher kann immer noch einbrechen, weil die „Offizielle Warnung" noch nicht ausgestellt wurde. Die Schnellspur schließt diese Lücke; die Langsamspur lässt die Stadt wochenlang ungeschützt.
4. Das „Warteschlangen"-Modell
Die Forscher entwickelten ein mathematisches Modell (wie eine Simulation einer Warteschlange in einem Café), um zu erklären, warum dies geschieht.
- Sie stellten fest, dass die Schnellspur den „Wartebereich" vollständig überspringt.
- Die Langsamspur zwingt Berichte, in einem „Wartebereich" (der NVD-Datenbank) zu sitzen, bevor sie überhaupt zum Schalter gelangen können.
- Dies liegt nicht daran, dass das Einsatzleitungs-Zentrum die Langsamspur ignoriert; es ist einfach so, wie das System aufgebaut ist. Die Struktur der Pipeline erzeugt auf natürliche Weise eine Verzögerung für externe Berichte.
5. Wer leistet die Arbeit?
Die Studie betrachtete auch die beteiligten Personen:
- Die Entdecker: Menschen, die die Risse finden, sind oft normale Leute mit kleinen Online-Followings.
- Die Reparierer: Die Personen, die den Code tatsächlich patchen, sind normalerweise die Gebäudeeigentümer, die in der Community sehr beliebt und vertrauenswürdig sind.
- Die Inspektoren: Die Personen, die die Berichte prüfen, sind eine Mischung. In der Schnellspur sind sie oft die Gebäudeeigentümer selbst (die eine Doppelarbeit leisten). In der Langsamspur sind sie ein spezialisiertes Team von Experten, die bereits Hunderte von Berichten geprüft haben.
Das Fazit
Das Papier kommt zu dem Schluss, dass das GitHub-Sicherheitssystem eine „Schnellspur" besitzt, die unglaublich effizient ist, aber derzeit untergenutzt wird. Die meisten Berichte nehmen immer noch die „Langsamspur", was eine gefährliche Verzögerung zwischen dem Zeitpunkt, an dem eine Reparatur bereit ist, und dem Zeitpunkt, an dem die Welt offiziell darüber informiert wird, erzeugt.
Die Forscher schlagen vor, dass, wenn mehr Menschen ermutigt werden könnten, die internen „Schnellspur"-Formulare (GRAs) anstelle des Wartens auf die externe Datenbank zu nutzen, die gesamte Stadt sicherer wäre und die Zeit zwischen einer Reparatur und einer Warnung dramatisch schrumpfen würde. Sie haben zudem alle ihre Daten und ihren Code veröffentlicht, damit andere diesen Verkehrsstau weiter untersuchen können.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.