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 die bereits von den Teams genutzten Systeme zu reparieren, werden sie in ein proprietäres Ökosystem gedrängt, über das sie keine Kontrolle haben. Bei komplett neuen Anwendungen 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 eigenen Projekt.
Der dritte Weg 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 eine CVE im Upstream behoben wird, wird der kleinste Codeabschnitt, der die Schwachstelle behebt, aus der neueren Version isoliert und sauber auf die ältere Version angewendet, die Sie bereits einsetzen. Zu überprüfen, ob sich sonst nichts geändert hat, erfordert echtes Fachwissen und kontinuierliche Wartung. Distributionen praktizieren Varianten davon schon seit Jahren. Dies über Anwendungsbibliotheken hinweg automatisch und in dem Tempo durchzuführen, in dem CVEs auftreten, ist jedoch ein ganz anderes Problem. Bei EOL-Paketen, für die kein Upstream-Fix in Aussicht steht, muss dennoch jemand die Sicherheitslücke verstehen und einen Fix für die bereits verwendete Version schreiben. Genau diese Arbeit steht nun als skalierbare Option für Anwendungsbibliotheken zur Verfügung – und genau hier stecken die meisten Teams fest. Der einzige Fall, in dem dies nicht zutrifft, ist, wenn noch überhaupt kein Upstream-Fix existiert. Wenn der Betreuer den Patch noch nicht geschrieben hat, gibt es nichts zu isolieren und anzuwenden. Die CVE bleibt so lange 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.
