Die Frist für eine kritische Abhängigkeitsschwachstelle läuft fast ab, aber im aktuellen Sprint ist keine Zeit für manuelle Tests, um sicherzustellen, dass die Produktion nicht beeinträchtigt wird. Das Verpassen der Behebungsfrist an sich ist bereits ein Mangel in Ihrem nächsten SOC-2- oder ISO-27001-Bericht, und das Risiko einer Ausnutzung wächst zudem durch fortschrittliche KI-Modelle. Ihnen bleiben zwei schlechte Optionen: die Produktentwicklung verlangsamen, um diese Schwachstelle zu patchen, oder Ihrem Sicherheitsteam und anderen Stakeholdern erklären, warum Sie eine wichtige SLA gebrochen haben.
Wenn Ihnen dieses Szenario bekannt vorkommt, sind Sie damit nicht allein. Unternehmen fallen im Wettlauf um das Schließen bekannter Schwachstellen und die Einhaltung ihrer Sicherheits-SLAs immer weiter zurück. Eine Studie von Verizon aus dem Jahr 2026 zeigt, dass die Ausnutzung von Schwachstellen die häufigste Ursache für bestätigte Sicherheitsvorfälle ist und gestohlene Zugangsdaten zum ersten Mal in der fast 20-jährigen Geschichte des Berichts überholt hat.
Die Behebung verliert weiter an Boden, da die Zahl der identifizierten Schwachstellen explosionsartig gestiegen ist. Dem gleichen Verizon-Bericht zufolge wurden 2025 nur 26 % der bekannten ausnutzbaren Schwachstellen (KEVs) vollständig behoben (gegenüber 38 % im Vorjahr), während die durchschnittliche Behebungszeit auf 43 Tage anstieg (verglichen mit 32 Tagen im Jahr zuvor). Der Verizon-Bericht führt dies darauf zurück, dass Unternehmen 50 % mehr kritische Schwachstellen zu patchen haben.
Warum passiert das immer wieder?
Es ist keineswegs abwegig zu erwarten, dass mit der wachsenden Bedeutung von Schwachstellen mehr Ressourcen in das Problem fließen und die Korrekturen Schritt halten. Wer jedoch in diesem Bereich arbeitet, weiß, dass dies einfach nicht der Fall war. Es gibt zwei Hauptgründe, warum sich dieses Problem verschlimmert, statt besser zu werden:
- Ein riesiger Teil der Abhängigkeiten wird im Wesentlichen nicht mehr gepflegt, steckt aber zu tief in Produktionssystemen, als dass man sie einfach herausreißen oder problemlos auf eine neuere Major-Version aktualisieren könnte. Man denke an
log4j. - SLA-Richtlinien und Compliance-Programme schert es nicht, ob es einen aktiven Maintainer gibt.
Was Teams heute tun: Die Phasen der SLA-Trauer
Wenn die Zeit knapp wird, durchlaufen die meisten Engineering-Teams eine vorhersehbare Schleife schlechter Optionen. Das erinnert stark an das klassische Kübler-Ross-Trauermodell.
Leugnung: Die meisten Teams beginnen damit, auf einen Upstream-Patch zu warten, doch es gibt keine Garantie, wann oder ob der Maintainer die Schwachstelle überhaupt patchen wird. Einige Maintainer korrigieren Fehler innerhalb von Tagen oder schneller, andere nicht. Verschärft wird dieses Problem bei weit verbreiteten, aber faktisch ungenutzten Paketen ohne echten Verantwortlichen. Das Warten lässt lediglich die SLA-Uhr ablaufen, ohne die Schwachstelle zu beheben.
Wut: Die problematische Abhängigkeit wird herausgerissen und ersetzt. Das sieht nach einer echten Lösung aus und ist es für heute wahrscheinlich auch. Wenn das neue Paket jedoch nächsten Monat eine CVE erhält und im Monat darauf noch eine, stecken Sie in einem Ersetzungszyklus fest, der Ihrem Team echte Zeit beim Produktbau kostet. Selten ist der eigentliche Austausch der Paketversion das Teure, sondern all die damit verbundenen Arbeiten zur Erfüllung von Abhängigkeitsprüfungen, zur Verifizierung der API-Kompatibilität und zur Durchführung von Tests, um sicherzustellen, dass kritische Anwendungsfunktionen in der Produktion nicht beschädigt werden.
Verhandeln: Während die SLA-Uhr tickt, beschließen Sie, eine Ausnahme zu beantragen. Das verschafft Ihnen mehr Zeit, um eine Lösung zu finden, löst aber das zugrundeliegende Problem nicht. Das Ticket ist heute zwar aus dem Dashboard verschwunden, aber Sie wissen, dass es wiederkommen wird. Schlimmer noch: Es taucht beim nächsten Audit oder wenn ein Kunden-Sicherheitsteam das Behebungsprotokoll prüft als Mangel auf. Einmal lässt sich das vielleicht verkraften, aber wenn sich ein Muster von Ausnahmen bildet, kann das schlimmer sein als eine einzelne verfehlte SLA-Frist.
Depression: Die letzte Option besteht darin, den Sicherheits-Patch selbst zu backporten. Das ist eine echte Lösung, wenn Sie die nötige Zeit aufbringen können, um die CVE zu verstehen, den Fix zu isolieren und ihn in die bestehende Codebasis zu cherry-picken. Der Nachteil: Sie übernehmen ab sofort die Verantwortung für diesen Patch und alle zukünftigen Patches für diese Bibliothek. Das erfordert Ressourcen, die Ihrem Team wahrscheinlich bei seinen Kernaufgaben fehlen werden.
Die Lösung: Aikido Libraries
Wenn man der Metapher bis zum Ende folgt, wäre die letzte Phase die Akzeptanz. Aufgeben und die Compliance-Auswirkungen hinnehmen oder das Risiko eines Systemabsturds eingehen. Akzeptieren Sie es nicht. Aikido Libraries durchbricht diesen Kreislauf.
Aikido Libraries liefert gepatchte Versionen Ihrer anfälligen Abhängigkeiten. Paketname und öffentliche API bleiben unverändert. Die einzige Änderung ist ein Suffix, das den Patch kennzeichnet, sowie eine Verknüpfung mit der Registry von Aikido.
Jeder Patch basiert auf dem Original-Fix des Maintainers. Aikido übernimmt die Upstream-Sicherheitsänderung und wendet sie auf die von Ihnen genutzte Version an. Anpassungen werden nur dort vorgenommen, wo es die ältere Laufzeitumgebung erfordert. Jeder Patch wird automatisch getestet, anschließend von einer Person überprüft und als Diff bereitgestellt, das Sie vor dem Mergen vollständig lesen können.
Die Transparenz des Patches ist entscheidend für das Vertrauen. Sie erhalten nicht den proprietären Fix von Aikido für die Schwachstelle, sondern den an Ihre Version angepassten Fix des Maintainers inklusive des vollständigen Diffs, 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 wird als „Hoch“ eingestuft. Die Version von Aikido Libraries wird zu jsonwebtoken 8.5.1-aikido.5 und backportet die Sicherheits-Fixes von jsonwebtoken 9.0.0 auf 8.5.1. Die Änderung besteht aus Ergänzungen: neuen Key-Validation-Dateien, von denen eine einen Kompatibilitäts-Shim für die ältere Node-Laufzeitumgebung enthält. Ein Upgrade auf 9.0.0 für denselben Fix hätte ein Major Release bedeutet, bei dem die Unterstützung für ältere Node-Versionen wegfällt und die Art und Weise geändert wird, wie verify() mit unsignierten Tokens umgeht.
Der Katalog von Aikido Libraries umfasst derzeit über 9.000 sichere Bibliotheken für JavaScript, Python, Java, .NET, PHP, Go und Ruby. Zudem veröffentlichen wir täglich 50 bis 100 neue Patches. Für angebundene Repositories stellen wir gepatchte, sichere Bibliotheken innerhalb von 48 Stunden bei bekannten, aktiv ausgenutzten Schwachstellen und innerhalb von 7 Tagen bei kritischen und hohen CVEs bereit.
Einmal aktivieren
Aikido Libraries funktioniert auf zwei Wegen. Für ein einzelnes Paket ist es eine Option im bestehenden AutoFix-Menü: Beheben Sie eine CVE ohne Upgrade, PR für PR. Für ein Repository werden Ihre Abhängigkeiten durch die Aktivierung fixiert und es wird täglich ein AutoFix-PR für CVEs versendet, die nach der Aktivierung bekannt wurden. Sie können die Funktion für ein einzelnes wichtiges Repository oder für Ihre gesamte Codebasis über die Aikido-Benutzeroberfläche aktivieren.
Dadurch sind Sie nicht an den abgesicherten Build gebunden. Führen Sie jederzeit ein Upgrade durch, wenn Sie die neuere API oder Funktionen wünschen, und Sie erhalten dennoch die damit verbundenen CVE-Fixes. Das Schließen einer CVE und das Ändern der Version sind fortan zwei getrennte Dinge.
Halten Sie Ihre SLAs jedes Mal ein
Geben Sie Aikido ein Repository an und innerhalb weniger Minuten erhalten Sie Ihren ersten, direkt merge-fähigen PR gegen eine echte CVE. Durchstöbern Sie den Katalog, um zu sehen, welche Ihrer Abhängigkeiten abgedeckt sind, oder schützen Sie ein Repository, um Ihren ersten Patch zu erhalten.
