Die Empfehlung lautet immer gleich, wenn ein Schwachstellen-Tool eine CVE meldet: Aktualisieren. Wechseln Sie zur gepatchten Version, damit Sie das Ticket schließen und weitermachen können. Das ist mittlerweile so sehr zur Gewohnheit geworden, dass niemand mehr innehält, um zu fragen, ob es tatsächlich funktionieren wird.
Die vorgeschlagene Lösung scheitert in dreierlei Hinsicht: Es gibt keine Version, auf die man aktualisieren könnte, und es wird auch nie eine geben; die gepatchte Version ist noch nicht verfügbar; oder die Lösung wird veröffentlicht und führt zu Fehlfunktionen in Ihrer Anwendung.
Kurz gesagt: Alle Best Practices und jedes Framework – von SOC 2 bis ISO 27001 – empfehlen, die Abhängigkeiten auf dem neuesten Stand zu halten. Ein Upgrade ist jedoch nicht gleichbedeutend mit einer Fehlerbehebung, und dennoch ist dies die einzige Lösung, die viele Tools bieten.
Es war nicht immer ein falscher Instinkt. Die Projektbetreuer haben (glücklicherweise) Sicherheitslücken in der neuesten Version behoben, und jahrelang war das ausreichend.
CVEs werden gemeldet > die Projektbetreuer schließen die Lücken > man führt ein Upgrade durch > man erhält den Fix.
Allerdings gehen die Projektbetreuer in der Regel nicht zurück und beheben Fehler in älteren Versionen. Daher haben sich Teams daran gewöhnt, immer auf die neueste Version zu aktualisieren, sobald dies möglich war, und Angreifer haben dieses Muster erkannt und gelernt, es auszunutzen. Wenn man nun ein Upgrade durchführt, um die CVE zu beheben, besteht die Möglichkeit, dass sich irgendwo im Update Malware befindet – daher ist das Herunterladen der neuesten Version nicht mehr automatisch sicher.
Anfang dieses Jahres gelang es Angreifern, ein Betreuerkonto zu kompromittieren , das für einige der am häufigsten heruntergeladenen Pakete auf npm verantwortlich war : „chalk“ und „debug“, die zusammen über zwei Milliarden Downloads pro Woche verzeichnen. Sie veröffentlichten bösartige Versionen über den offiziellen Kanal, und jede Pipeline, die auf automatische Aktualisierung eingestellt war, lud diese direkt herunter. Teams, die sich an bewährte Verfahren hielten, verbreiteten innerhalb weniger Minuten Malware.
Es ist eine Situation, in der man nur verlieren kann. Entweder man bleibt auf dem neuesten Stand und riskiert, Malware einzuschleusen, oder man friert die Software ein und baut Sicherheitsrückstände auf. Das bezeichnen wir als „Upgrade-Falle“. Die Entscheidung für die verwendete Version und die Entscheidung für die darauf angewendeten Sicherheitspatches müssen nicht zwangsläufig miteinander übereinstimmen.
Die drei Gründe, warum ein Upgrade fehlschlägt
Natürlich funktioniert „Upgrade“ in vielen Fällen und ist nach wie vor wichtig. Es gibt jedoch drei Situationen, in denen es nicht funktioniert.
Der erste Fall tritt ein, wenn es keine feste Version gibt, auf die man umsteigen kann (und es auch nie geben wird). Nehmen wir Anfrage, Einer der am häufigsten verwendeten HTTP-Clients in Node, der seit 2020 als veraltet gilt. Und dennoch taucht er immer noch überall auf, meist mitgebracht von einem übergeordneten Paket, das seit Ewigkeiten niemand mehr angerührt hat. Wenn man ein SCA auf „request“ anwendet, meldet das Tool eine CVE wegen Umgehung der Schutzmaßnahmen gegen serverseitige Request-Forgery (SSRF). Ratet mal, was laut dem SCA hier die Lösung ist? Genau: ein Upgrade.
Aber der Haken daran ist: Es gibt nichts, worauf man aufrüsten könnte, und das wird es auch nie geben. request wird seit Jahren nicht mehr gepflegt. Das wird in der Sicherheitsempfehlung quasi auch so gesagt, da darauf hingewiesen wird, dass die Schwachstelle nur Versionen betrifft, die der Betreuer nicht mehr unterstützt (also alle Versionen). In diesem Fall bedeutet „Upgrade“ also eigentlich, das System komplett neu zu installieren. request heraus und hin zu etwas wie axios oder node-fetch. Das bedeutet eine Neuprogrammierung und eine Migration, und solange niemand Zeit dafür hat, bleibt die CVE einfach liegen.
Die zweite Art der Aktualisierung tritt ein, wenn es keine Korrektur gibt noch auch wenn das Paket noch vorhanden ist. Die beliebte Bibliothek lodash Im vergangenen Jahr gab es eine Zeit lang zwei bekannt gewordene Sicherheitslücken, von denen alle veröffentlichten Versionen bis einschließlich 4.17.23 betroffen waren. Da dies die aktuellste Version war, gab es kein Update, auf das man umsteigen konnte. npm audit hat die CVEs gemeldet und darauf hingewiesen, dass noch kein Patch verfügbar sei. Auch wenn die Empfehlung zum Upgrade also durchaus sinnvoll war, war sie in der Praxis nicht umsetzbar, da die gepatchte Version noch nicht veröffentlicht worden war.
Der dritte Fall tritt ein, wenn der Patch veröffentlicht wird und Ihre Anwendung dadurch nicht mehr funktioniert. CVE-2026-48937 „in Node“ ist ein aktuelles Beispiel. Der Fix für die Sicherheitslücke war im Lieferumfang eines SEMVER-MAJOR Aktualisierung der nghttp2 Abhängigkeit und die Entfernung der Unterstützung für die HTTP/2-Prioritätssignalisierung. Das anfällige Verhalten und die entfernte Funktion waren Teil desselben zugrunde liegenden Codes, sodass es nicht möglich war, den Sicherheitspatch zu installieren, ohne gleichzeitig die Kompatibilitätsänderung zu übernehmen. Die Nutzer mussten nach setPriority und .priority() und sie zu entfernen, bevor sie überhaupt ein Upgrade durchführen konnten.
Das ist das Risiko bei jedem Upgrade. Eine neue Version kann das Verhalten eines Pakets so stark verändern, dass etwas, das zuvor funktioniert hat, nicht mehr läuft, andere Abhängigkeiten ebenfalls aktualisiert werden müssen oder es sich um eine Hauptversion handelt, die erst migriert werden muss, bevor sie überhaupt installiert werden kann.
Und um noch einen Schritt weiter zu gehen: Wenn man ein Paket aktualisiert, muss man möglicherweise fünf weitere mitaktualisieren. Eines davon könnte dann etwas beschädigen, von dem das System abhängt. Die Entwickler stehen dann vor der Wahl zwischen einem Roadmap-Punkt, der Umsatz generiert, und dem Upgrade. Ratet mal, was gewinnt 😬. Am Ende hat man dann technische Schulden und einen Berg an CVEs.
Wie KI die Spielregeln verändert hat
Die meisten Unternehmen haben einen CVE-Rückstand, der zu groß ist, um ihn abzuarbeiten, und sie sind beunruhigt, weil die neuesten Modelle Schwachstellen schneller aufspüren können. Noch bedrohlicher ist jedoch, dass sie mittelschwere CVEs so miteinander verknüpfen können, dass daraus ein kritisches Exploit-Muster entsteht. Das derzeitige Modell, bei dem die Schwachstellen gescannt, priorisiert und an die Entwickler weitergeleitet werden, lässt sich nicht schnell genug skalieren, um dieses Problem in den Griff zu bekommen. KI verschärft ein bereits bestehendes Problem effektiv und macht es für Unternehmen noch dringlicher, Abhilfe zu schaffen.
Was die Branche dagegen unternimmt
Lange Zeit war ein Upgrade die einzige realistische Lösung. Die darauf folgenden CVE-Rückstände und fehlerhaften Builds waren eine vorhersehbare Folge der begrenzten Auswahlmöglichkeiten. Im Großen und Ganzen gibt es drei Ansätze zur Lösung dieses Problems. Bei zwei davon wird ein Problem gegen ein anderes eingetauscht. Der dritte Ansatz schließt die CVE tatsächlich, ohne das Risiko einer neuen zu bergen.
Der erste Ansatz ist die Überprüfung am Verwendungsort. Bevor ein Paket in Ihre Build-Umgebung gelangt, wird es überprüft: Ist die Installation dieser Abhängigkeit sicher? Dies ist eine notwendige Sicherheitsebene, insbesondere nach Angriffen wie „Chalk“ und „Debug“. Für bereits in der Produktion befindliche anfällige Pakete ist dieser Ansatz jedoch nicht geeignet. Es handelt sich eher um eine Vorabkontrolle als um eine Korrekturmaßnahme, und außerhalb dieses Anwendungsbereichs bleibt die Lösung weiterhin ein Upgrade.
Der zweite Ansatz besteht darin, Teams auf einen gehärteten Ersatz-Stack umzustellen. Anstatt die bereits von den Teams genutzten Systeme zu reparieren, werden sie in das proprietäre Ökosystem eines anderen Anbieters gedrängt. Bei Neuentwicklungen mag das funktionieren, doch bei Produktionssystemen, die an bestimmte Bibliotheken und Basis-Images gebunden sind, wird die Fehlerbehebung dadurch zu einem Migrationsprojekt. Ist man erst einmal drin, wird der Ausstieg zu einem eigenständigen Projekt.
Der dritte Ansatz besteht darin, den Fix auf die bereits im Einsatz befindliche Version zurückzuportieren. Die meisten Unternehmen verfügen weder über die Kapazitäten noch über das Fachwissen oder die Bereitschaft, dies zu tun. Wenn ein CVE im Upstream behoben wird, wird der kleinste Codeabschnitt, der das Problem behebt, aus der neueren Version isoliert und sauber auf die ältere Version angewendet, die Sie bereits nutzen. Die Überprüfung, dass sich nichts anderes geändert hat, erfordert echtes Fachwissen und kontinuierliche Wartung. Distributionen praktizieren dies in unterschiedlicher Form schon seit Jahren. Dies jedoch über Anwendungsbibliotheken hinweg automatisch und in dem Tempo durchzuführen, in dem CVEs auftreten, ist ein ganz anderes Problem. Dieser Ansatz bedeutet, dass Sie die Version beibehalten, der Ihre Anwendung bereits vertraut, nur den Fix anwenden und somit weder CVEs in einer eingefrorenen Version ansammeln noch die neueste Version mit allem, was dazu gehört, übernehmen.
Stellen Sie sich Ihren Software-Stack wie ein Haus vor, in dem Sie schon seit Jahren wohnen. Die meisten Tools prüfen entweder, was durch die Tür hereinkommt, händigen Ihnen eine Liste mit Reparaturarbeiten aus und sagen Ihnen, Sie sollen das selbst regeln, oder sie bitten Sie, in ein neues, kleineres Haus zu ziehen, das sie gebaut haben. Das Haus, in dem Sie bereits wohnen, zu renovieren, ist das, was die meisten Teams eigentlich wollen.
Mit Aikido gibt es nun eine Option, die genau das ermöglicht: Schwachstellen in den Open-Source-Paketen zu beheben, auf die Ihre Anwendung angewiesen ist, ohne ein Upgrade durchführen zu müssen.
