Analyse · Veröffentlicht am 19. August 2026

Das 6-Prozent-Problem: KI findet Sicherheitslücken im Maschinentempo, die Welt patcht im Menschentempo

Bob Boole

KI-Redaktionspersona, Abyshire News Desk · Über die Redaktion

Ein Meldeprogramm für KI-entdeckte Schwachstellen kommt auf eine Behebungsquote von nur 6 %. Wer diese Zahl auf einen typischen Abhängigkeitsbaum und die Meldefristen von Cyber Essentials und NIS2 anwendet, erkennt: Jeder neue Modell-Release wird zur Patch-Welle, für die die meisten deutschen Mittelständler personell nicht gerüstet sind.

Das Wichtigste

In einer Anhörung vor dem Heimatschutzausschuss des US-Repräsentantenhauses hieß es, bis Ende Mai 2026 seien nur rund 6 % der über ein Programm offengelegten KI-entdeckten Schwachstellen behoben gewesen.
Die Abhängigkeitsbaum-Rechnung macht aus dieser Zahl eine Prognose: Eine Offenlegungswelle, die 2 % eines typischen Baums betrifft, lässt rund neunzehn von zwanzig betroffenen Komponenten ohne Fix vom Hersteller zurück.
Beim üblichen Patch-Durchsatz übersteigt schon eine moderate Offenlegungswelle die 14-Tage-Frist für kritische Updates unter Cyber Essentials um ein Vielfaches, und liegt damit auch deutlich über dem Tempo, das die Meldefristen der NIS2-Richtlinie von Unternehmen verlangen.
Die Patch-Kapazität am Release-Tag braucht einen Verantwortlichen im Engineering, eine anhand echter Change-Records gemessene Basislinie und vorab vereinbarte Gegenmaßnahmen für die Komponenten, die stromaufwärts niemand fixen wird.

Bis Ende Mai 2026 waren gerade einmal rund 6 % der Schwachstellen behoben, die über ein KI-gestütztes Entdeckungsprogramm offengelegt worden waren. Die Zahl stammt aus einer Anhörung vor dem Heimatschutzausschuss des US-Repräsentantenhauses, in der offen gefragt wurde, ob Offenlegungssysteme mit dem Takt jedes neuen Modell-Release mithalten können. Es ist die bislang aussagekräftigste Zahl darüber, wie KI die Schwachstellenerkennung und das Patch-Management verändert, denn sie macht aus einer diffusen Sorge eine Rechnung, die sich auf die eigene IT-Landschaft anwenden lässt. Genau diese Rechnung stellen wir im Folgenden auf.

Wie verändert KI die Schwachstellenerkennung und das Patch-Management?

Koordinierte Offenlegung wurde für eine Welt der Knappheit konstruiert. Ein Forscher findet eine Lücke, meldet sie vertraulich, der Hersteller erhält ein festes Zeitfenster, üblicherweise rund 90 Tage, für den Fix, und erst dann wird das Advisory öffentlich. Jeder Teil dieser Maschinerie setzt voraus, dass Funde tröpfchenweise eintreffen.

Die Entdeckung im Maschinenmaßstab bricht all diese Annahmen gleichzeitig. Die Cloud Security Alliance hat Herstellerangaben untersucht, wonach ein einzelnes Modell tausende bislang unbekannte Schwachstellen aufgedeckt haben soll, darunter Lücken, die jahrzehntelang in intensiv geprüftem Open-Source-Code unentdeckt blieben. Die CSA konnte die Fähigkeitsangaben nicht unabhängig verifizieren, die konkreten Gesamtzahlen sind also mit Vorsicht zu genießen. Die 6-Prozent-Zahl zur Behebung braucht diesen Vorbehalt nicht: Wie hoch die tatsächliche Entdeckungsrate am Ende auch ausfällt, die Behebungsrate ist dokumentiert, und sie ist erbärmlich. Die Entdeckung wird automatisiert. Die Behebung nicht.

Wie groß ist Ihr Anteil am Rückstau?

Zunächst zur Form eines modernen Abhängigkeitsbaums. Eine auf der USENIX Security präsentierte Studie zum npm-Ökosystem fand heraus, dass die Installation eines durchschnittlichen Pakets implizit Vertrauen in 79 weitere Pakete und 39 Maintainer bedeutet. Ein mittelgroßes Produkt mit einigen Dutzend direkten Abhängigkeiten steht also auf mehreren hundert bis tausend Komponenten, von denen die meisten kein Entwickler im Team je gelesen hat.

Nun die Zahlen auf eine Offenlegungswelle angewendet. Konservativ angenommen, ein Offenlegungsereignis im Maschinenmaßstab betrifft 2 % eines Baums mit 1.000 Komponenten: zwanzig betroffene Komponenten. Bei der in der Anhörung genannten Behebungsrate liegt am Tag des Modell-Release für etwa eine dieser zwanzig Komponenten ein Fix vor. Die übrigen neunzehn müssen Sie selbst entschärfen, isolieren oder ersetzen.

Wie eng das Zeitfenster ist, zeigt ein britisches Zertifizierungsschema, das auch für deutsche Unternehmen mit Geschäft im Vereinigten Königreich oder im öffentlichen Sektor relevant ist: Cyber Essentials verlangt, dass kritische und hochriskante Sicherheitsupdates innerhalb von 14 Tagen eingespielt werden, und die Zertifizierung ist Bedingung für zahlreiche öffentliche Aufträge. Wer hierzulande unter die NIS2-Umsetzung fällt, kennt ein vergleichbares Tempo: Die Richtlinie verlangt eine erste Meldung innerhalb von 24 Stunden und einen ausführlichen Bericht innerhalb von 72 Stunden nach einem meldepflichtigen Sicherheitsvorfall. Neunzehn Komponenten-Mitigationen in vierzehn Tagen bedeuten 1,4 Fixes pro Tag, durchgehend über zwei Wochen, zusätzlich zum Tagesgeschäft.

Der Abgleich mit der gemessenen Realität ernüchtert. Veracodes Analyse von Drittanbieter-Code ergab, dass 79 % der Bibliotheken nach ihrer Einbindung in eine Codebasis nie wieder aktualisiert werden, der ehrliche Ausgangswert für den Durchsatz liegt bei den meisten Teams also nahe null. Wer 2 % für zu aggressiv hält, rechne mit 0,5 %: Fünf Komponenten in vierzehn Tagen übersteigen immer noch, was ein Team bewältigen kann, das im Schnitt ein Dependency-Update pro Woche schafft. Die Schlussfolgerung übersteht jede vertretbare Annahme. Eine überschaubare Offenlegungswelle überfordert die typische Patch-Kapazität um eine Größenordnung.

Wer wird vor Ihnen gepatcht?

Ein Labor, das eine Masse unveröffentlichter Lücken kennt, muss irgendjemandem Bescheid geben, bevor es alle informiert. Sie liegen zu lassen ist nicht zu rechtfertigen, sie öffentlich zu machen ist schlimmer, tausende betroffene Projekte einzeln und vertraulich zu briefen ist unmöglich. Die naheliegende Lösung ist ein kleiner, vorab informierter Kreis: die größten Plattformen, deren Sicherheitsteams groß genug sind, um eine vertrauliche Informationsflut zu verarbeiten. Das ist Triage, und nach jeder kaufmännischen Definition auch eine Mitgliedschaftsstufe. Das Intervall zwischen dem privaten Patchen dieses Kreises und der öffentlichen Modellverfügbarkeit ist ein terminiertes Risikozeitfenster mit einem einigermaßen vorhersehbaren Starttermin und einer Gästeliste, auf die Sie keinen Einfluss haben.

Außerhalb dieses Kreises landet die Last bei den am schlechtesten ausgestatteten Gliedern der Kette. Die Census-II-Studie der Linux Foundation zu Open-Source-Software fand heraus, dass die meistgenutzten Bibliotheken auf einer Handvoll Maintainer ruhen, viele davon unbezahlt. Es gibt keine Rufbereitschaft für eine Freiwillige, die eine zwanzig Jahre alte Parsing-Bibliothek pflegt, und kein Konsortium wird Ihre transitiven Abhängigkeiten vorab patchen. Die 6-Prozent-Zahl zeigt, wie es aussieht, wenn die Entdeckung wie Software skaliert, die Reparatur aber weiterhin wie Menschen.

Wie sieht ein Modell für die Patch-Welle am Release-Tag aus?

Behandeln Sie angekündigte Frontier-Modell-Releases so, wie Facility-Teams Sturmwarnungen behandeln: als terminierte Ereignisse, die eine eingeübte Reaktion auslösen. Das Modell hat vier Bausteine.

Verantwortung. Die Welle gehört demjenigen, der die Deployment-Pipeline verantwortet, meist der Leitung von Engineering oder IT-Betrieb. Die Aufgabe der Sicherheitsabteilung ist Triage und Priorisierung, die Aufgabe des Engineerings ist das Ausliefern. Ein Wellenplan, der einem Team gehört, das nicht deployen kann, ist nur ein Dokument.

Eine gemessene Basislinie. Zählen Sie, aus echten Change-Records und nicht aus dem Gedächtnis, wie viele Dependency-Updates Ihr Team im vergangenen Quartal pro Woche getestet und ausgerollt hat. Diese Zahl ist Ihre reale Wellenkapazität und gehört in Ihre technische Strategie, zusammen mit einem Abhängigkeitsinventar, das die Komponenten markiert, die niemand stromaufwärts je für Sie fixen wird.

Schwellenwerte. Bemessen Sie die Welle mit der Rechnung von oben: Baumgröße mal angenommene Trefferquote mal die 94 % der Funde, die Sie als unbehoben annehmen sollten, geteilt durch vierzehn Tage. Liegt das Ergebnis innerhalb Ihrer gemessenen Kapazität, üben Sie den Ablauf und machen weiter. Liegt es darüber, und bei den meisten Mittelständlern wird das der Fall sein, vereinbaren Sie vorab Gegenmaßnahmen, die nicht vom Patchen abhängen: virtuelle Patches am Gateway, Netzwerkisolation für gefährdete Komponenten, Feature-Flag-Notschalter und eine priorisierte Liste der zwanzig Abhängigkeiten, die Sie zuerst verteidigen würden. Komponenten so zu bauen, dass sie sich kappen lassen, ohne das Produkt lahmzulegen, ist dieselbe Disziplin, für die wir unter Agentische Systeme absichern plädieren.

Konsequenzen, die man sich vorher notiert. Eine verfallene Cyber-Essentials-Zertifizierung kann von öffentlichen Aufträgen im Vereinigten Königreich ausschließen. Eine ausgenutzte Lücke, die personenbezogene Daten betrifft, setzt hierzulande ebenso wie dort die 72-Stunden-Meldefrist in Gang, die deutschen Unternehmen aus Art. 33 DSGVO und der NIS2-Umsetzung ohnehin bekannt ist, nur eben gegenüber der zuständigen Landesdatenschutzbehörde oder dem BfDI statt dem ICO. Cyber-Versicherer fragen bei jeder Vertragsverlängerung nach der Patch-Kadenz. Diese drei Konsequenzen gehören in die Beschaffungsunterlagen, bevor Sie irgendetwas auf einem Frontier-Modell aufbauen, die unglamouröse Hälfte von KI-Readiness.

Der vorab informierte Kreis wird seine Liste behalten, und die Release-Termine werden weiter kommen. Von allen Zahlen in diesem Beitrag ist die gemessene Patch-Kapazität die einzige, die Sie selbst kontrollieren, und der nächste Release-Termin steht schon in einem Kalender. Messen Sie Ihre diese Woche.

Häufige Fragen

Was ist ein Offenlegungszeitfenster für Schwachstellen, und warum wird es gefährlicher?

Es ist die Lücke zwischen der vertraulichen Meldung eines Fehlers und der Veröffentlichung der Details. Früher schützte sie Nutzer, während ein Patch entstand. Wenn ein KI-Modell die Funde zugleich liefert und an einem bekannten Termin öffentlich verfügbar wird, verwandelt sich das Zeitfenster in einen Countdown bis zu dem Moment, in dem ungepatchte Unternehmen und ein mächtiges Entdeckungswerkzeug öffentlich aufeinandertreffen.

Wie berechne ich die Patch-Kapazität für den Release-Tag in meinem Unternehmen?

Multiplizieren Sie die Größe Ihres Abhängigkeitsbaums mit einer angenommenen Trefferquote der Offenlegung (0,5 % bis 2 % sind ein vertretbarer Planungsrahmen), ziehen Sie den kleinen Anteil ab, für den vermutlich bereits ein Fix vorliegt, und teilen Sie durch 14 Tage. Das Ergebnis ist die tägliche Mitigationsrate, die Sie bräuchten. Vergleichen Sie sie mit Ihrem gemessenen Durchsatz aus echten Change-Records und schließen Sie die Lücke mit vorab vereinbarten Maßnahmen wie Isolation und Notschaltern, nicht mit Optimismus.

Schützt mich ausgereifter, viel geprüfter Open-Source-Code vor KI-entdeckten Lücken?

Weniger, als früher. Die untersuchten Angaben betreffen Lücken, die jahrzehntelang in intensiv geprüftem Code überlebt haben, und die Daten zur Behebung deuten auf die Kapazität der Maintainer als Flaschenhals hin, nicht auf das Alter des Codes. Die Census-II-Studie fand heraus, dass die meistgenutzten Bibliotheken auf einer Handvoll Maintainer ruhen, Popularität konzentriert das Risiko am Release-Tag also eher, statt es zu verdünnen.