Vor einer Woche wurde der Copy-Fail-Schwachstelle aufgedeckt. Hyunwoo Kim erkannte umgehend, dass die offizielle Korrektur nicht ausreichend war und legte am selben Tag ein Patch vor. Dabei folgte er den in der Linux-Welt – insbesondere im Netzwerkbereich – üblichen Standards: Er informierte spezifische Sicherheitsingenieure des Linux-Kernels über das Sicherheitsrisiko und behandelte die Behebung öffentlichkeitswirksam, jedoch diskret. Sein Ziel bestand darin, lediglich den ursprünglichen Patch zu veröffentlichen und so eine „Blockade" bezüglich der Meldung eines schwerwiegenden Schwachstellenbefundes herbeizuführen: Eine stillschweigende Übereinkunft unter Eingeweihten, einige Tage lang Stillschweigen zu bewahren. Doch jemand bemerkte diese Änderung, erkannte ihre sicherheitsrelevanten Implikationen und machte sie öffentlich. Da die Information bereits geleckt war, galt das Blockadeabkommen als beendet, woraufhin alle Details zur Schwachstelle offengelegt wurden. Dieser Vorfall verdeutlichte die Spannungen zwischen zwei unterschiedlichen Ansätzen zum Umgang mit Schwachstellen und löste Überlegungen darüber aus, wie KI-beschleunigte Prozesse diesen Status quo verändern könnten. Auf der einen Seite steht die Kultur der „koordinierten Offenlegung". Dies ist möglicherweise die verbreitetste Methode im Bereich Cybersicherheit: Nach Entdeckung einer Sicherheitsschwachstelle wird der Maintainer zunächst privat informiert, gefolgt von einer bestimmten Frist für dessen Reparaturmaßnahmen (in der Regel 90 Tage). Das Ziel besteht darin sicherzustellen, dass ein Patch bereitgestellt ist, bevor Informationen über die Schwachstelle veröffentlicht werden. Der anderen Position entspricht die Kultur der „Schwachstelle gleich Schwachstelle", die besonders im Linux-Community weit verbreitet ist. Ihr Argument lautet: Wenn der Kernel etwas tut, was er nicht tun sollte, kann dies immer noch von einem Angreifer genutzt werden. Daher muss die Schwachstelle möglichst schnell und unbemerkt behoben werden. In der Masse enormer Codeänderungen bleiben solche Patches oft unentdeckt, wodurch Zeit gewonnen wird, um Systeme zu patchen. Diese Herangehensweise war nie perfekt und steht nun angesichts zunehmender Fähigkeiten künstlicher Intelligenz bei der Aufspürung von Schwachstellen vor schweren Herausforderungen. Heute häufen sich Sicherheitskorrekturen, sodass die Prüfung von Commit-Historien zunehmend attraktiv erscheint: Das Signal-Rausch-Verhältnis hat sich verbessert. Zudem wird es kostengünstiger und effizienter, jede einzelne Einreichung mittels KI zu bewerten. Langfristige Informationsblockaden sind jedoch ebenfalls kaum mehr tragbar. Die bisherigen Erkennungsrhythmen waren langsamer: Wurde eine Schwachstelle entdeckt und dem Hersteller eine 90-tägige Offenlegungsfrist gewährt, konnte man davon ausgehen, dass währenddessen fast niemand sonst sie finden würde. Heute hingegen scannen zahlreiche Teams, unterstützt durch KI, fortlaufend nach Softwarefehlern, womit dieses Szenario entfallen ist. Im vorliegenden Fall meldete Kuan-Ting Chen dieselben ESP-Schwachstelle nur neun Stunden nachdem Kim seinen Bericht eingereicht hatte. Paradoxerweise können Blockaden sogar Risiken erhöhen: Sie erzeugen eine falsche Nicht-Dringlichkeitsatmosphäre und beschränken den Kreis an Personen, die an der Fehlerbehebung beteiligt sein dürfen. Zwar gibt es hierzu keine abschließende Klärung, doch ich persönlich halte kurzzeitige Blockaden derzeit für die bessere Kompromisslösung, wobei dieser Zeitraum mit fortschreitender Entwicklung weiter verkürzt werden müsste. Zum Glück beschleunigt KI sowohl die Angriffsseite als auch die Verteidigung, wodurch ursprünglich aufgrund ihrer Kürze wirkungslose Blockadefristen nun wieder praktikabel erscheinen.