Der Rat ist immer derselbe, wenn ein Schwachstellen-Tool eine CVE meldet: Upgrade. Wechseln Sie zur gepatchten Version, damit Sie das Ticket schließen und weitermachen können. Es ist zu einem solchen Reflex geworden, dass niemand mehr hinterfragt, ob es tatsächlich funktioniert.
Der vorgeschlagene Fix scheitert auf drei spezifische Weisen. Es gibt keine Version, auf die man upgraden könnte und wird es auch nie geben, die gepatchte Version wurde noch nicht ausgeliefert oder der Fix wird ausgeliefert und legt Ihre Anwendung lahm.
Kurz gesagt: Best Practices und jedes Framework von SOC2 bis ISO27001 fordern, dass Sie Ihre Abhängigkeiten auf dem neuesten Stand halten. Doch ein Upgrade ist nicht gleichbedeutend mit einer Behebung, und dennoch ist es die einzige Antwort, die viele Tools haben.
Es war nicht immer der falsche Instinkt. Maintainer haben (glücklicherweise) Schwachstellen in der neuesten Version behoben, und jahrelang war das ausreichend.
CVEs werden gemeldet > Maintainer patchen sie > Sie führen ein Upgrade durch > Sie erhalten den Fix.
Doch Maintainer gehen in der Regel nicht zurück und beheben ältere Versionen. Daher gewöhnten sich Teams daran, immer auf die neueste Version upzugraden, wenn sie konnten, und Angreifer bemerkten dieses Muster und lernten, es auszunutzen. Wenn Sie jetzt ein Upgrade durchführen, um die CVE zu beheben, besteht die Möglichkeit, dass sich irgendwo im Update Malware befindet, sodass das Herunterladen der neuesten Version nicht mehr automatisch sicher ist.
Anfang dieses Jahres kompromittierten Angreifer ein Maintainer-Konto, das für einige der meist heruntergeladenen Pakete auf npm. chalk und debug verantwortlich war, die zusammen über zwei Milliarden Downloads pro Woche verzeichneten. Sie veröffentlichten bösartige Versionen über den offiziellen Kanal, und jede Pipeline, die auf Auto-Update eingestellt war, zog sie direkt herein. Teams, die Best Practices folgten, lieferten innerhalb weniger Minuten Malware aus.
Es ist eine Zwickmühle. Sie bleiben aktuell und riskieren, Malware einzuschleusen, oder Sie frieren ein und häufen Security Debt an. Das nennen wir die Upgrade-Falle. Die Version, die Sie ausführen, und die darauf angewendeten Sicherheitsfixes müssen nicht dieselbe Entscheidung sein.
Die drei Arten, wie Upgrades scheitern
Natürlich funktioniert „Upgrade“ oft und ist immer noch wichtig. Doch es gibt drei Situationen, in denen es scheitert.
Die erste ist, wenn es keine gefixte Version gibt, auf die man umsteigen könnte (und auch nie geben wird). Nehmen Sie Anfrage, Einer der meistgenutzten HTTP-Clients in Node, der seit 2020 als veraltet gilt. Und doch taucht er immer noch überall auf, meistens durch ein übergeordnetes Paket, das seit Ewigkeiten niemand mehr angefasst hat. Wenn man ein SCA-Tool über `request` laufen lässt, meldet das Tool eine CVE für einen Server-Side Request Forgery (SSRF) Mitigation Bypass. Und was ist laut SCA-Tool die Lösung? Richtig, ein Upgrade.
Der Haken ist jedoch, dass es nichts gibt, worauf man upgraden könnte, und das wird es auch nie geben. request seit Jahren nicht mehr gewartet wurde. Die Empfehlung besagt dies quasi, indem sie darauf hinweist, dass die Schwachstelle nur Versionen betrifft, die der Maintainer nicht mehr unterstützt (was jede Version ist). In diesem Fall bedeutet „Upgrade“ also tatsächlich, das Entfernen von request und die Umstellung auf etwas wie axios oder node-fetch. Das ist ein Rewrite und eine Migration, und es bedeutet, dass die CVE so lange bestehen bleibt, bis jemand Zeit dafür hat.
Das setzt voraus, dass der Fix vom Maintainer kommt. Für EOL-Pakete muss immer noch jemand die Schwachstelle verstehen und einen Fix für die bereits verwendete Version schreiben. Distributionen tun dies seit Jahren für Pakete auf Betriebssystemebene. Der gleiche Ansatz existiert jetzt für Anwendungsbibliotheken, wo die meisten Teams feststecken.
Die zweite Art von Upgrade ist, wenn der Fix nicht existiert noch obwohl das Paket noch aktiv ist. Die beliebte Bibliothek lodash verbrachte letztes Jahr eine Zeitspanne mit zwei offengelegten Schwachstellen, die jede veröffentlichte Version bis einschließlich 4.17.23 betrafen. Da dies die neueste Version war, gab es nichts, worauf man upgraden konnte. npm audit kennzeichnete die CVEs und meldete, dass kein Fix verfügbar war. Obwohl der Ratschlag zum Upgrade sinnvoll war, war er nicht umsetzbar, da das gepatchte Release noch nicht veröffentlicht worden war.
Die dritte Situation ist, wenn der Fix veröffentlicht wird und Ihre Anwendung beschädigt. CVE-2026-48937 in Node ist ein aktuelles Beispiel. Der Fix für die Schwachstelle wurde gebündelt mit einem SEMVER-MAJOR Update der nghttp2 Abhängigkeit und der Entfernung der HTTP/2 Priority Signaling Unterstützung. Das anfällige Verhalten und die entfernte Funktion waren Teil desselben zugrunde liegenden Codes, sodass es keine Möglichkeit gab, den Sicherheitsfix zu übernehmen, ohne gleichzeitig die Breaking Change in Kauf zu nehmen. Benutzer mussten nach `grep` suchen nach setPriority und .priority() und diese entfernen, bevor sie überhaupt ein Upgrade durchführen konnten.
Dies ist das Risiko bei jedem Upgrade. Eine neue Version kann das Verhalten eines Pakets so stark ändern, dass etwas Funktionierendes kaputtgeht, andere Abhängigkeiten dazu zwingt, ebenfalls upzugraden, oder als Major-Version erscheint, die eine Migration erfordert, bevor sie überhaupt installiert werden kann.
Und um noch einen Schritt weiterzugehen: Wenn Sie ein Paket aktualisieren, müssen Sie möglicherweise fünf andere aktualisieren. Eines davon könnte etwas beschädigen, wovon Ihr System abhängt. Das Engineering-Team steht dann vor der Wahl zwischen einem Roadmap-Element, das Einnahmen generiert, und dem Upgrade. Ratet mal, welches gewinnt 😬. Sie enden dann mit technischer Schuld und einem Stapel von CVEs.
Wie KI die Spielregeln geändert hat
Die meisten Unternehmen haben einen CVE-Backlog, der zu groß ist, um ihn abzuarbeiten, und sie sind nervös, weil die neuesten Frontier-Modelle Schwachstellen schneller finden können. Aber was noch bedrohlicher ist: Sie können mittlere CVEs so miteinander verketten, dass sie zu einem kritischen Exploit-Muster werden. Das aktuelle Modell des Scannens, Triage und der Zuweisung dieser Arbeit an Ingenieure skaliert nicht schnell genug, um dieses Problem zu bewältigen. KI verschärft ein bestehendes Problem effektiv und macht es für Organisationen dringlicher, es zu beheben.
Was die Branche dagegen unternimmt
Ein Upgrade war lange Zeit die einzig realistische Antwort. Die daraus resultierenden CVE-Rückstände und fehlerhaften Builds waren eine vorhersehbare Konsequenz der begrenzten Auswahlmöglichkeiten. Es gibt im Wesentlichen drei Ansätze für dieses Problem. Zwei davon tauschen ein Problem gegen ein anderes ein. Der dritte kommt dem tatsächlichen Schließen der CVE am nächsten, ohne eine neue zu erzeugen.
Der erste Ansatz ist das Screening am Punkt der Nutzung. Bevor ein Paket Ihren Build erreicht, wird es geprüft: Ist diese Abhängigkeit sicher zu installieren? Es ist eine notwendige Schicht, besonders nach Angriffen wie Chalk und Debug. Aber es passt nicht für anfällige Pakete, die bereits in Produktion sind. Es ist eher ein Gate als ein Fix, und außerhalb dieses Bereichs bleibt die Antwort ein Upgrade.
Der zweite Ansatz besteht darin, Teams auf einen gehärteten Ersatz-Stack umzustellen. Anstatt das zu beheben, was Teams bereits betreiben, werden sie in das proprietäre Ökosystem eines anderen gedrängt. Es kann für Greenfield-Anwendungen funktionieren, aber für Produktionssysteme, die an bestimmte Bibliotheken und Basis-Images gebunden sind, verwandelt es die Remediation in ein Migrationsprojekt. Sobald man drin ist, ist das Herauskommen ein eigenes Projekt.
Zu validieren, dass sich nichts anderes geändert hat, erfordert echtes Fachwissen und fortlaufende Wartung. Distributionen machen dies seit Jahren in verschiedenen Versionen. Dies automatisch über Anwendungsbibliotheken hinweg zu tun, in dem Tempo, in dem CVEs auftauchen, ist ein völlig anderes Problem. Für EOL-Pakete, bei denen kein Upstream-Fix kommt, muss immer noch jemand die Schwachstelle verstehen und einen Fix für die bereits verwendete Version schreiben. Diese gleiche Arbeit existiert jetzt als skalierbare Option für Anwendungsbibliotheken, wo die meisten Teams feststecken. Der einzige Fall, in dem dies nicht zutrifft, ist, wenn noch überhaupt kein Upstream-Fix existiert. Wenn der Maintainer den Patch nicht geschrieben hat, gibt es nichts zu isolieren und anzuwenden. Die CVE bleibt bestehen, bis jemand dies tut.
Sie behalten die Version, der Ihre Anwendung bereits vertraut, wenden nur den Fix an und sammeln keine CVEs gegen eine eingefrorene Version an oder ziehen das neueste Release mit allem, was dazugehört.
Stellen Sie sich Ihren Software-Stack wie ein Haus vor, in dem Sie seit Jahren leben. Die meisten Tools überprüfen entweder, was durch die Tür kommt, geben Ihnen eine Liste von Reparaturen und sagen Ihnen, Sie sollen es selbst regeln, oder bitten Sie, in ein neues, kleineres Haus zu ziehen, das sie gebaut haben. Das Haus zu reparieren, in dem man bereits lebt, ist das, was die meisten Teams tatsächlich wollen.
Es gibt jetzt eine Option, die genau das tut: Schwachstellen in den Open-Source-Paketen beheben, von denen Ihre Anwendung abhängt, ohne ein Upgrade durchzuführen – mit Aikido Libraries.
