Der Beitrag ordnet die aktuelle Welle von Clearinghouse-Ankündigungen als Symptom eines Strukturwandels ein. Solche Sammelstellen für Schwachstelleninformationen seien an sich nichts Neues: Als Beispiele nennt Chainguard die NVD, die GitHub Advisory Database, OSV sowie herstellereigene Schwachstellenportale. Neu sei jedoch die Art der Daten, die nun gebündelt werde: vor der Offenlegung bekannte Schwachstellen aus der langen Kette von Open-Source-Abhängigkeiten, von kritischen Projekten bis hin zu kleinen, kaum bekannten Bibliotheken.

Warum diese Funde so relevant sind, erklärt Chainguard mit der Ausführungspraxis moderner Software. Ein Fehler in einer unscheinbaren Abhängigkeit laufe mit denselben Rechten wie die Anwendung, die sie geladen hat. Damit könne selbst ein kleines Blatt im Abhängigkeitsbaum den gesamten Prozess kompromittieren. Der Datenpool selbst sei aber nicht die eigentliche Leistung. „Daten sind träge“, lautet die Kernaussage: Ein Eintrag in einer Datenbank behebe noch keine Schwachstelle.

Entscheidend sei die „Umsetzung“: Aus einem Fund müsse ein neu gebautes, getestetes und signiertes Artefakt werden, idealerweise rückportiert auf die Version, die Nutzer tatsächlich einsetzen, und verfügbar in der Registry, auf die ihre Werkzeuge bereits zugreifen. Chainguard beschreibt genau diese Pipeline als sein eigentliches Produkt. Das eigene Build-System beobachte Tausende Open-Source-Projekte und reagiere unmittelbar, wenn ein Advisory erscheint: Quellcode holen, neu bauen, testen, signieren. Die meisten CVEs würden laut Unternehmen in etwa zwei Tagen behoben; bei der überwältigenden Mehrheit sei kein menschlicher Eingriff nötig. Für von CISA als aktiv ausgenutzt eingestufte Schwachstellen gelte eine Frist von einem Tag. Insgesamt habe Chainguard weit über 100.000 solcher Fälle behoben.

Als Ursache für den Zustrom nicht öffentlicher Schwachstellen nennt der Beitrag den Einsatz von Modellen wie Mythos. Effektive Ergebnisse entstünden demnach nicht dadurch, dass man ein Modell nur auf eine Datei ansetzt, sondern indem man es mit einer laufenden Anwendung, Debugger, Sandbox und Quellcode im Kontext arbeiten lässt und es mit einem unscharfen, gegnerischen Auftrag konfrontiert: „Zerstöre das.“ Dabei fänden die Modelle nicht nur Fehler im eigenen Code, sondern übergreifende Ketten in veralteten Open-Source-Komponenten, teils mehrere Ebenen tief in Abhängigkeiten, die niemand mehr pflegt.

Genau daraus entstehe der Bedarf nach Clearinghouses: Diese Funde seien privat, weil sie einer „geladenen Waffe“ gleichkämen, und sie träfen gemeinsame Ziele, weil in zahllosen Anwendungen dieselben wenigen Dutzend Bibliotheken stecken. Die einzelnen Funde überlappten laut Chainguard kaum, wohl aber der betroffene Code. Deshalb seien größere Pools im Vorteil: Sie deckten gemeinsame Bibliotheken umfassender ab, bündelten die Kommunikation mit Maintainern und erhöhten die Reichweite für nachgelagerte Schutzmaßnahmen.

Zugleich warnt der Beitrag vor Fragmentierung. Ein einziges globales Clearinghouse hält Chainguard wegen Konzentrationsrisiken für unrealistisch; genannt wird unter anderem APRA, Australiens Bankenaufsicht, die laut Beitrag von Banken sowohl hohe Geschwindigkeit im Umgang mit KI als auch das Management von Konzentrationsrisiken verlangt. Viele kleine Pools seien aber ebenfalls problematisch, weil sie bei denselben Bibliotheken aufeinanderprallten: überlappende Embargos, konkurrierende Fixes und Offenlegungen, die andere Prozesse sprengen.

Den zeitlichen Druck untermauert Chainguard mit mehreren Kennzahlen. Die mittlere Zeit bis zur Ausnutzung werde inzwischen auf minus sieben Tage geschätzt: Bei den im vergangenen Jahr bewaffnet eingesetzten Schwachstellen habe die Ausnutzung im Durchschnitt eine volle Woche vor öffentlichem Patch begonnen. Früher habe dieser Wert bei mehr als 60 Tagen gelegen; 2024 sei die Marke von null unterschritten worden. Mandiant, Google und CrowdStrike erzählten dieselbe Geschichte; CrowdStrike beziffere den Anteil der ausgenutzten Schwachstellen, die schon vor öffentlicher Offenlegung getroffen wurden, auf 42 Prozent.

Als Maßstab für seriöse Anbieter nennt Chainguard deshalb zwei Kennzahlen: die mediane Zeit vom Fund bis zum neu gebauten, getesteten und signierten Fix sowie den Anteil der Fälle ohne menschlichen Eingriff; und den Anteil der ausgelieferten Fixes, die tatsächlich upstream im Quellcode gelandet sind. Nur so lasse sich unterscheiden, ob ein Anbieter lediglich eigene Kunden versorge oder das Problem breiter verkleinere. Für Athena nennt das Unternehmen bislang mehr als 20.000 aufgenommene Funde, über 2.000 Patches und 500 Projekte. Künftig wolle Chainguard außerdem die eigenen Kennzahlen veröffentlichen, darunter die mediane Bearbeitungszeit, den Automatisierungsgrad und den Anteil der Upstream-Fixes.