Die Frist im Rahmen eines SLA für eine kritische Abhängigkeitsschwachstelle läuft bald ab, aber im aktuellen Sprint haben Sie keinen Spielraum für die manuellen Tests, die erforderlich sind, um sicherzustellen, dass der Produktivbetrieb nicht beeinträchtigt wird. Das Versäumen der Behebungsfrist selbst ist bereits ein Befund in Ihrem nächsten SOC-2- oder ISO-27001-Bericht, doch das Risiko einer Ausnutzung wächst zudem mit der Weiterentwicklung der KI-Modelle. Ihnen bleiben zwei schlechte Optionen: Entweder verlangsamen Sie die Produktentwicklung, um diese Schwachstelle zu beheben, oder Sie erklären Ihrem Sicherheitsteam und anderen Beteiligten, warum Sie gegen ein wichtiges SLA verstoßen haben.
Wenn Ihnen das oben beschriebene Szenario bekannt vorkommt, sind Sie nicht allein. Unternehmen geraten im Wettlauf um die Behebung bekannter Sicherheitslücken und die Einhaltung ihrer Sicherheits-SLAs immer weiter ins Hintertreffen. Eine im Jahr 2026 veröffentlichte Studie von Verizon zeigt, dass die Ausnutzung von Sicherheitslücken die häufigste Ursache für bestätigte Sicherheitsvorfälle ist und damit erstmals in der fast 20-jährigen Geschichte des Berichts den Diebstahl von Zugangsdaten überholt hat.
Die Behebung von Sicherheitslücken verliert aufgrund einer explosionsartigen Zunahme identifizierter Schwachstellen weiter an Boden. Aus demselben Verizon-Bericht geht hervor: Nur 26 % der bekannten, ausgenutzten Sicherheitslücken (KEVs) wurden im Jahr 2025 vollständig behoben – ein Rückgang gegenüber 38 % im Vorjahr –, während die mediane Behebungszeit von 32 Tagen im Vorjahr auf 43 Tage anstieg. Der Verizon-Bericht führt dies darauf zurück, dass Unternehmen 50 % mehr kritische Sicherheitslücken zu beheben hatten.
Warum passiert das immer wieder?
Es ist nicht abwegig anzunehmen, dass mit zunehmender Bedeutung von Sicherheitslücken mehr Ressourcen in die Lösung des Problems fließen und die Korrekturen Schritt halten würden. Wer jedoch in diesem Bereich tätig ist, weiß, dass dies einfach nicht der Fall ist. Es gibt zwei Hauptgründe, warum sich dieses Problem verschlimmert, anstatt sich zu bessern:
- Ein großer Teil der Abhängigkeiten wird im Grunde nicht mehr gepflegt, ist jedoch zu tief in den Produktionssystemen verankert, als dass man sie einfach entfernen oder problemlos auf eine neuere Hauptversion umstellen könnte. Man denke an
log4j. - Bei den SLA-Richtlinien und den Programmen „ compliance “ spielt es keine Rolle, ob es einen aktiven Betreuer gibt.
Was Teams heute tun: Die Phasen der SLA-Trauer
Wenn die Zeit knapp wird, durchlaufen die meisten Ingenieurteams eine vorhersehbare Abfolge schlechter Optionen. Das ähnelt stark dem klassischen Kübler-Ross-Trauermodell.
Verleugnung: Die meisten Teams warten zunächst auf einen Patch vom Upstream-Entwickler, doch es gibt keine Garantie dafür, wann – oder ob überhaupt – der Betreuer die Sicherheitslücke beheben wird. Manche Betreuer beheben das Problem innerhalb weniger Tage oder sogar noch schneller, andere hingegen nicht. Dieses Problem verschärft sich bei weit verbreiteten, aber praktisch nicht gepflegten Paketen, die quasi keinen Verantwortlichen haben. Das Warten lässt lediglich die Zeit Ihrer SLA ablaufen, ohne dass die Sicherheitslücke behoben wird.
Wut: Die problematische Abhängigkeit herausreißen und ersetzen. Das sieht nach einer echten Lösung aus – und ist es für den Moment wahrscheinlich auch. Doch wenn die neue Paketversion nächsten Monat eine CVE erhält und im Monat danach eine weitere, stecken Sie in einem Kreislauf von Ersetzungen fest, der Ihrem Team wertvolle Zeit bei der Produktentwicklung kostet. Selten ist es der Austausch der Paketversion an sich, der Sie wirklich Zeit kostet, sondern all die damit verbundenen Arbeiten: die Einhaltung von Abhängigkeitsprüfungen, die Überprüfung der API-Kompatibilität und das Ausführen von Tests, um sicherzustellen, dass keine kritischen Anwendungsfunktionen in der Produktion beeinträchtigt werden.
Verhandlung: Da die SLA-Frist abläuft, beschließen Sie, eine Ausnahmegenehmigung zu beantragen. Dadurch gewinnen Sie mehr Zeit, um eine Lösung zu finden, doch das zugrunde liegende Problem wird dadurch nicht gelöst. Das Ticket ist für heute aus Ihrem Dashboard verschwunden, aber Sie wissen, dass es wieder auftauchen wird. Schlimmer noch: Es wird als Beanstandung auftauchen, sobald ein Auditor oder das Sicherheitsteam eines Kunden das Behebungsprotokoll überprüft. Einmal lässt sich das wahrscheinlich noch verkraften, aber wenn sich ein Muster von Ausnahmegenehmigungen entwickelt, kann dies schlimmer sein als eine einzelne versäumte SLA-Frist.
Depression: Die letzte Möglichkeit besteht darin, den Sicherheitspatch selbst zurückzuportieren. Diese Option ist eine echte Lösung, wenn Sie die Zeit aufbringen können, die CVE zu verstehen, die Korrektur zu isolieren und sie gezielt in die bestehende Codebasis zu integrieren. Der Nachteil ist, dass Sie nun für diesen Patch und alle zukünftigen Patches für diese Bibliothek verantwortlich sind. Dies ist ein Ressourceneinsatz, der Ihr Team wahrscheinlich von seiner Kernaufgabe ablenkt.
Die Lösung: „ Aikido “-Bibliotheken
Würden wir diese Metapher bis zum Ende durchdenken, wäre die letzte Phase die Akzeptanz. Aufgeben und den Schaden von „ compliance “ hinnehmen oder eine Trennung riskieren. Akzeptiere das nicht. „ Aikido Libraries“ durchbricht diesen Kreislauf.
Aikido Libraries stellt gepatchte Versionen Ihrer anfälligen Abhängigkeiten bereit. Der Paketname und die öffentliche API bleiben unverändert. Die einzige Änderung besteht in einem Suffix, das den Patch kennzeichnet, sowie einem Verweis auf die Registry von Aikido.
Jeder Patch basiert auf einer vom Betreuer selbst erstellten Korrektur. „ Aikido “ übernimmt die Sicherheitsänderung aus dem Upstream und wendet sie auf die von Ihnen verwendete Version an. Anpassungen werden nur dort vorgenommen, wo die ältere Laufzeitumgebung dies erfordert. Jeder Patch wird automatisch getestet, anschließend von einem Mitarbeiter überprüft und als Diff bereitgestellt, den Sie vor dem Zusammenführen vollständig einsehen können.
Die Transparenz der Patches ist entscheidend für das Vertrauen. Sie erhalten nicht die proprietäre Korrektur von Aikido für die Sicherheitslücke, sondern die an Ihre Version angepasste Korrektur des Betreuers – inklusive des vollständigen Diff, falls Sie diesen überprüfen möchten.
Schauen wir uns ein konkretes Beispiel an. Die Bibliotheksversion jsonwebtoken 8.5.1 hat eine CVE-2022-23529 als „Hoch“ eingestuft. Die Version der „ Aikido “-Bibliotheken lautet jsonwebtoken 8.5.1-aikido.5 und portiert die Sicherheitskorrekturen aus jsonwebtoken 9.0.0 auf 8.5.1. Die Änderung besteht aus Ergänzungen: neue Dateien zur Schlüsselvalidierung, von denen eine einen Kompatibilitäts-Shim für die ältere Node-Laufzeitumgebung enthält. Das Upgrade auf 9.0.0 denn dieselbe Korrektur hätte ein großes Release erfordern, bei dem die Unterstützung für ältere Node-Versionen weggefallen wäre und sich die Art und Weise geändert hätte, wie verify() verarbeitet Token ohne Vorzeichen.
Der Katalog von „ Aikido “ umfasst derzeit mehr als 9.000 sichere Bibliotheken für JavaScript, Python, Java, .NET, PHP, Go und Ruby. Außerdem stellen wir täglich 50 bis 100 neue Patches bereit. Für registrierte Repositorys stellen wir gepatchte, sichere Bibliotheken innerhalb von 48 Stunden für bekannte, bereits ausgenutzte Sicherheitslücken und innerhalb von 7 Tagen für CVEs der Schweregrade „Critical“ und „High“ bereit.
Schalte es einmal ein
Aikido Die Bibliotheken funktionieren auf zwei Arten. Für ein einzelnes Paket ist dies eine Option im bestehenden AutoFix-Menü: Schließen Sie ein CVE ohne Upgrade, jeweils einen PR nach dem anderen. Für ein Repo werden durch die Aktivierung Ihre Abhängigkeiten festgelegt und es wird täglich ein AutoFix-PR für CVEs erstellt, die nach der Aktivierung bekannt gegeben wurden. Sie können die Funktion für ein einzelnes wichtiges Repo oder für Ihre gesamte Codebase über die Benutzeroberfläche unter „ Aikido “ aktivieren.
Nichts davon bindet Sie an die gesicherte Version. Führen Sie ein Upgrade durch, wann immer Sie die neuere API oder Funktionen nutzen möchten, und Sie erhalten weiterhin die damit verbundenen CVE-Korrekturen. Das Schließen der CVE und die Änderung der Version sind nicht mehr ein und dieselbe Entscheidung.
Halten Sie Ihre SLAs stets ein
Richten Sie Aikido auf ein Repo aus, und innerhalb weniger Minuten erhalten Sie Ihren ersten merge-bereiten PR für eine echte CVE. Stöbern Sie im Katalog, um zu sehen, welche Ihrer Abhängigkeiten abgedeckt sind, oder schützen Sie ein Repo, um Ihren ersten Patch zu erhalten.
