Die Absorptionslücke: Warum Änderungen heute schneller ausgeliefert als akzeptiert werden

KI hat sich in kürzester Zeit zur Standardtechnologie entwickelt, um Fehler, Probleme in der Benutzererfahrung oder Sicherheitslücken aufzuspüren. Dank KI werden diese Probleme heute in Maschinengeschwindigkeit gefunden und behoben: Fixes entstehen in Minuten, Hunderte Patches gehen in einem einzigen Zyklus raus.

Worin wir allerdings nicht besser geworden sind: diese Änderungen sicher zu verarbeiten. Und Absorption ist kein Durchsatzproblem, das sich per Automatisierung lösen lässt. Es ist der menschliche Akt des Bemerkens, Abwägens und Entscheidens, ob eine Änderung wirklich sicher ist, bevor sie durchläuft. Davon gibt es derzeit kaum eine Variante, die in Maschinengeschwindigkeit funktioniert.

Entdeckung und Erzeugung sind vorausgeeilt, die Fähigkeit zu sehen und zu entscheiden nicht. Die meisten echten Probleme beim Massen-Patching entstehen aus genau dieser Lücke. Und die Kosten tragen nicht diejenigen, die die Änderung erzeugen. Stattdessen rollen sie meist nach unten durch, zu denen, die am wenigsten dagegen ausgerüstet sind.

So wirkt sich die Absorptionslücke auf QA und IT Operations aus

Die Probleme beim Massen-Patching beginnen bei den Teams für Qualitätssicherung (QA) und IT-Betrieb, von denen erwartet wird, dass sie einen großen Patch-Durchlauf verarbeiten. Ihr Schutz vor einer fehlerhaften Änderung war immer die Zeit. Testschwerpunkte, Pilotgruppen, gestaffelte Rollouts und Beobachtungsphasen existieren, damit ein einzelner Fehler auffällt, bevor er die gesamte Flotte trifft. Zeit ist der Erkennungsmechanismus.

Wenn aber vierzig Fixes gemeinsam ausgerollt werden und drei Tage später etwas kaputtgeht (siehe die jüngsten kumulativen Updates von Microsoft zum Patchday im September 2026, die zu massenhaften Ausfällen der Remotedesktopdienste (RDS) auf Windows Server 2019, 2022 und 2025 führten), kann niemand sagen, welcher Patch das Problem verursacht hat. Denn es gab kein Zeitfenster, in dem die Variablen isoliert waren. Die Prüfqualität des Teams sinkt zugunsten der Geschwindigkeit.

Schnellere Patches bedeuten nicht automatisch bessere Fixes

Eine Ebene weiter oben erklärt dieselbe Lücke, warum so viele Patches oberflächlich bleiben. Wenn der Workflow von LLMs erzeugt wird, geht „hier ist der Fehler, hier ist der Fix“ schnell, das Verstehen dagegen langsam. Eine KI liefert Prüfung und Lösung in Sekunden. Herauszufinden, warum dieser Fehler überhaupt existiert und wo dasselbe Muster sonst noch steckt, kostet weiterhin Zeit und braucht einen Menschen.

Weil Erzeugung billig ist und Ursachenanalyse nicht, verschiebt sich das Volumen zum billigen Ende. Man bekommt punktuelle Fixes, die jeweils einen Einzelfall schließen und die zugrunde liegende Schwäche unangetastet lassen können, bereit, im nächsten Quartal als leicht verändertes Problem wieder aufzutauchen. Dieselbe Lücke im anderen Kostüm: Wir erzeugen Fixes schneller, als wir Verständnis erzeugen, und liefern die Differenz aus, als wäre sie Fortschritt.

Genau hier nehmen viele an, dass Automatisierung die Lücke schließt. Tut sie nicht. Zumindest nicht vollständig, noch nicht. Automatisierte Testsuiten prüfen das, woran jemand vorher gedacht hat. KI fügt eine nützliche Ebene hinzu und erkennt mehr Muster als eine statische Suite, doch beide sind an das gebunden, was antizipiert wurde. Keines von beidem ersetzt die QA-Fachkraft, die sich eine Änderung ansieht und das bemerkt, was niemand spezifiziert hat: den Fehlerfall, der nie ein Testfall war, weil ihn sich bislang niemand vorgestellt hat.

Automatisierung verkleinert das Feld, das ein Mensch im Blick behalten muss, aber sie ersetzt den Menschen nicht. So zu tun, als wäre es anders, sorgt dafür, dass der nicht vorgestellte Fehler unbemerkt ausgeliefert wird.

So wirken sich KI-generierte Sicherheitsmeldungen auf Open-Source-Maintainer aus

Die letzte Ebene ist die, über die niemand spricht. Ein großer Teil der Software stützt sich auf Open-Source-Bibliotheken, und ein Großteil dieses Fundaments wird von sehr wenigen unbezahlten Freiwilligen gepflegt. Log4j hat das greifbar gemacht: eine Logging-Bibliothek, die weltweit in Unternehmenssoftware steckt, von einer Handvoll Freiwilliger am Leben gehalten und so tief in Abhängigkeitsbäumen vergraben, dass die meisten Unternehmen gar nicht wussten, dass sie sie einsetzen.

Der Maintainer von curl, einer Open-Source-Anwendung, hat sich offen frustriert über eine Flut KI-generierter Schwachstellenmeldungen geäußert, die glaubwürdig wirken und häufig falsch sind. Eine haltlose Meldung kostet den Absender dreißig Sekunden und den Maintainer Stunden, um sie zu widerlegen, denn eine Sicherheitsbehauptung lässt sich nicht gefahrlos ignorieren, ohne sie zu prüfen. Wer ganz unten im Stack absorbiert, ist oft eine einzige erschöpfte Person, und wir haben ihr im Grunde einen Feuerwehrschlauch in die Hand gedrückt.

Die Asymmetrie verschärft das Ganze. Wer als Verteidiger eine echte Schwachstelle findet, meldet sie offen und drückt dieser freiwilligen Person eine tickende Uhr in die Hand. Ein Bedrohungsakteur meldet gar nichts und behält eine private Waffe, die auf alles Nachgelagerte zielt. Die Verzweiflung, die das bei ausgebrannten Maintainern auslöst, ist genau die Öffnung für Supply-Chain-Angriffe, wie sie die XY-Utils-Backdoor ausgenutzt hat. Dieselbe Lücke, dasselbe Durchrollen nach unten, nur hat sich die Person ganz unten nie für diesen Job gemeldet.

So schließen Sie die Absorptionslücke im Patch-Management

Nichts davon spricht gegen Patching. Patching ist enorm wichtig. Ungepatchte Systeme werden zwangsläufig ausgenutzt (der Data Breach Investigations Report 2026 (DBIR) belegt das), und das Zeitfenster zwischen Veröffentlichung und Angriff wird immer kürzer.

Wenn Änderungen jedoch schneller entstehen, als sie verarbeitet werden können, lautet die Antwort: in Absorption investieren, nicht nur in Beschleunigung.

In Ihrer eigenen Umgebung heißt das, genau zu wissen, was Sie tatsächlich betreiben, bis hinunter zu den tiefen Abhängigkeiten, Änderungen gestaffelt auszurollen, damit Zeit ihre Arbeit tun kann, in Communitys vernetzt zu bleiben und auf der Bereitstellungsebene zu mindern, wenn ein Fix von oben spät oder nie kommt. Für die Ebene, auf die sich alle verlassen, heißt das, die Kapazität von Maintainern als das zu behandeln, was sie ist: gemeinsame Infrastruktur. Wenn Sie auf eine Open-Source-Bibliothek setzen, helfen Sie mit, die Last zu tragen: Finanzieren Sie das Projekt, bringen Sie Entwicklungszeit ein, geben Sie Ihre Fixes nach oben zurück und sichten Sie echte Probleme, statt nur Meldungen einzureichen. Die Lücke am unteren Ende des Stacks ist nicht das Problem einzelner Freiwilliger. Sie ist das Problem aller, denn alle stehen darauf.

Unterm Strich sind beschleunigte Massen-Patching-Zyklen ein Risikomanagement-Problem, kein Geschwindigkeitsproblem. Die Geschwindigkeit verbessert sich ohnehin weiter. Absorption verbessert sich nur, wenn wir sie bewusst einbauen, und jede Minderung, die zählt, ist eine Möglichkeit, das menschliche Urteilsvermögen zurückzukaufen, das Änderungen in Maschinengeschwindigkeit oft wegnehmen.

Heben Sie sich eine echte menschliche Prüfung für die Änderungen mit dem höchsten Risiko auf, statt überall nur einen oberflächlichen Stempel zu verteilen. Nichts davon beseitigt das Risiko, aber es bepreist es, grenzt es ein und legt die Entscheidung zurück in die Hände von jemandem, der den Kontext dafür hat und die Autorität, „noch nicht“ zu sagen. Patching ist wichtig, doch blindes Patching tauscht nur ein sichtbares Risiko gegen ein unsichtbares. Mit Patch Intelligence KI von NinjaOne ist das Risikoverständnis bereits eingebaut. Die Lösung zeigt, was mehrere Quellen über einen bestimmten Patch sagen, und gibt diese Erkenntnisse an Techniker:innen weiter. So können Menschen entscheiden, ob ein Patch ein Risiko für das Unternehmen darstellt oder ob sie besser noch warten.

Das Ziel ist nicht nur, schneller zu werden. Es geht darum, zu wissen, worauf Sie sich dabei einlassen.