Eine Brücke bleibt dank eines festen Prüfungsplans fünfzig Jahre lang in Betrieb, wobei sie durchgehend auf Lasten getestet und gewartet wird. Ein Triebwerk fliegt jahrzehntelang im selben Design unter kontinuierlicher behördlicher Aufsicht. In den meisten Ingenieursdisziplinen sind ein stabiles, bewährtes Design gepaart mit aktiver Wartung das Ziel. Neuere Designs werden weitaus kritischer beäugt, da sie noch nie wirklich auf Herz und Nieren geprüft wurden.
Doch aus irgendeinem Grund gilt in der Softwareentwicklung das Gegenteil. Die neueste Version wird als die sicherste angesehen. Und diese Intuition ist in der Vergangenheit gewaltig nach hinten losgegangen. Eine Backdoor befand sich in zwei spezifischen Versionen von xz-utils, den Versionen 5.6.0 und 5.6.1, eingeschleust von einem Infiltrator, der zwei bis drei Jahre damit verbracht hatte, die Freigabeberechtigungen zu erlangen. Wer noch die ältere 5.4er-Linie betrieb, war zu keinem Zeitpunkt gefährdet, aber wer die neueste Version heruntergeladen hatte – also das, was Sicherheitsteams üblicherweise empfohlen wird –, nutzte einen mit einer Backdoor versehenen SSH-Pfad. Die offizielle Empfehlung der CISA lautete danach: ein Downgrade durchführen, kein Upgrade.
Wir haben bereits zuvor in unserem Beitrag mit dem Titel „die Upgrade-Falle“ argumentiert, dass das Patchen im Moment des Auftretens einer CVE eine Scheinlösung ist; man entscheidet sich letztlich nur zwischen dem Einfrieren des Zustands und dem Akzeptieren sämtlicher Änderungen, die mit dem Fix einhergehen. xz-utils zeigt uns die Kehrseite derselben Medaille. Auf dem alten Stand zu bleiben war die sichere Wahl, und die neueste Version war die Falle.
Eine Möglichkeit, dies zu überprüfen, besteht darin, ein Sicherheitsteam nach der Anzahl seiner offenen CVEs zu fragen – man wird wahrscheinlich prompt eine Antwort erhalten. Wenn man jedoch fragt, warum ein bestimmtes Paket oder ein Container-Image genau diese Version ausführt, bekommt man höchstwahrscheinlich ein „weiß nicht“ zur Antwort. Das ist eben so, nicht wahr? Meistens basiert es schlicht darauf, was beim Projektstart verfügbar war, und ein Upgrade schien mehr Aufwand zu sein, als es wert war. Wenn man noch einen Schritt weitergeht und nach einer schriftlichen Dokumentation dieser Entscheidung fragt, erntet man vermutlich eher eine schärfere Reaktion im Sinne von: „Warum sollten wir das überhaupt tun?“
Wo läuft das also schief?
Häufig wird Entwickelnden weisgemacht, dass ein Container-Image oder Paket risikoreicher wird, je älter die Versionsnummer ist. Aber das xz-utils -Beispiel beweist, dass das nicht stimmt; die ältere Version war sicher, weil sie noch frei von Schadcode war und die Teams, die sie einsetzten, nicht sofort beim Erscheinen zur neuesten Version geeilt waren. Natürlich besteht die Möglichkeit, dass viele Teams schlicht noch nicht zum Aktualisieren gekommen waren, es aber eigentlich vorgehabt hatten. Das ist immer noch besser als gar nicht zu wissen, welche Version man ausführt oder warum – denn das ist das eigentliche Versagen.
Stattdessen müssen Teams bedenken: Wenn sie eine Bibliotheksversion besitzen, die getestet, verstanden und vertrauenswürdig ist, hat es echten Wert, diesen stabilen Zustand beizubehalten. Die Überwachung beginnt in dem Moment, in dem eine entwickelnde Person, ein Agent oder eine Build-Pipeline ein Basis-Container-Image oder ein Open-Source-Paket anfordert, indem es bewertet wird, bevor es in die Umgebung gelangt. Es ist die erste Entscheidung in einer Kette von Entscheidungen.
Auch ein Upgrade ist eine bewusste Entscheidung
Irgenwann wird eine neue Version erscheinen, doch das Patchen einer CVE bedeutet, dass man auch alles andere akzeptiert, was mit dieser Version ausgeliefert wurde. Dazu gehören Dinge wie transitive Abhängigkeiten, veränderte Standardeinstellungen und Code-Pfade, die niemand im Team jemals gelesen hat. Meistens ist dieses Risiko unsichtbar und es geht alles gut. Aber – und das ist ein großes Aber –, es kann auch schiefgehen. lodash verbrachte einen Teil des Jahres 2026 mit einer offengelegten Schwachstelle zur Remotekartenerstellung bzw. beliebigen Code-Injektion, die jede veröffentlichte Version betraf. Als der Fix schließlich als Version 4.18.0 ausgeliefert wurde, schlug er sofort fehl, weil der Patch eine andere interne Funktion einwechselte, die niemals importiert worden war, wodurch reale Projekte innerhalb eines Tages abstürzten.
Die Version wurde umgehend zurückgezogen, mit dem Hinweis an die Nutzer, stattdessen Folgendes zu verwenden: lodash 4.17.21 zurückzukehren. Die Breaking Change hatte nichts mit der Schwachstelle selbst zu tun; es war ein Paketierungsfehler, der zusammen mit dem Sicherheits-Fix ausgeliefert worden war. Der tatsächliche Fix erschien erst in Version 4.18.1.
Keine der zur Auswahl stehenden Optionen war tatsächlich sicher. Ein Upgrade auf 4.18.0 führte sofort zu fehlerhaften Builds. Das Verbleiben auf 4.17.21 ließ die Sicherheitslücke offen, während jede Version vor 4.18.0 angreifbar blieb. Einige Teams führten ein Downgrade auf 4.17.x durch, speziell um dem fehlerhaften Build zu entkommen, und tauschten so einen funktionierenden Build gegen einen aktiven Code-Injektionspfad ein, ohne sich dessen notwendigerweise bewusst zu sein.
In diesem Fall befanden sich die Teams in der besten Position, die wussten, ob ihre eigene Anwendung überhaupt den betroffenen _.template Pfad mit nicht vertrauenswürdigen Eingaben aufrief, und dieses reale Risiko gegen die fehlerhafte Alternative abwägen konnten, anstatt standardmäßig blind zu handeln, ohne die tatsächlichen Kosten zu kennen.
Die Schwachstelle beheben, ohne alles Drumherum auszutauschen
Backporting verändert die Gleichung. Es wendet den spezifischen Fix für die jeweilige Schwachstelle auf die bereits laufende Version an, anstatt alles andere zu übernehmen, was upstream gleichzeitig veröffentlicht wurde. Wenden Sie dies auf ein Container-Image an, wird die CVE behoben, ohne dass ein neues Basis-Image erzwungen wird. Wenden Sie es auf ein Paket an, wird derselbe Fix durchgeführt, ohne einen erzwungenen Sprung auf das neueste Release – genau der Sprung, der reale Projekte beschädigt hat, die unter lodash 4.18.0 laufen. Sie sind in der Lage, das Sicherheitsproblem zu beheben, ohne alles Drumherum zu verändern.
Eine SBOM sollte ihren Nutzen verdienen und nicht nur existieren
Eine SBOM wird, wie so viele Compliance-bezogene Dokumente, oft einmal erstellt und abgeheftet. Das verrät Ihnen zwar, was sich an dem Tag im System befand, als jemand den Bericht erstellt hat. Aber die SBOM kann weit mehr für Ihre Sicherheitslage tun. Sie kann als vertrauenswürdige Software-Baseline dienen und Ihnen helfen, diese kontinuierlich zu verwalten. Dazu stellen Sie sicher, dass sie aktuell gehalten und bei neuen Offenlegungen mit diesen abgeglichen wird. Das ist für mich das eindeutigste Zeichen dafür, dass ein Unternehmen die von ihm betriebene Software tatsächlich nachhält, anstatt sich einfach auf dem Status quo auszuruhen.
Wir möchten, dass die SBOM nicht nur ein Inventar oder ein Compliance-Artefakt ist. Sie sollte ein kontrollierter, aktiv gepflegter Bereich sein.
Was muss sich also ändern?
All dies sind Entscheidungen, die getroffen werden müssen. Einige betreffen eine bestimmte Software-Komponente zu einem bestimmten Zeitpunkt, wie das Evaluieren einer Anfrage, das Festlegen (Pinning) Ihrer Version und Backporting anstelle eines erzwungenen Upgrades. Andere, wie die Frage, ob Sie eine SBOM aktuell halten, betreffen Ihre etablierten Prozesse. Jede einzelne ist im Grunde eine Entscheidung darüber, wem man vertraut.
Der einfachere Weg ist, die Dinge einfach so zu belassen, wie sie sind, weil es ja „funktioniert“. Aber stimmt das „es funktioniert“ wirklich? Nur weil etwas funktioniert, bedeutet das nicht, dass es immer funktionieren wird, dass es der sicherste Weg ist oder dass es die beste Art zu arbeiten ist.
Aus unserer Sicht wäre der proaktivste, sicherheitsbewussteste Ansatz, Änderungen am Einstiegspunkt zu kontrollieren – Pakete zu evaluieren, bevor eine Entwickelnde, ein Agent oder ein Build-System sie konsumieren. Von dort aus sollten Sie die Befugnis haben, proaktiv zu entscheiden, was hereinkommt, dem zu vertrauen, was Sie pinnen, es zu pflegen und es nur dann zu ändern, wenn es einen Grund dafür gibt.
Auf einer Version zu bleiben sollte nicht bedeuten, ungeschützt zu bleiben. Aikido Libraries portiert den Fix auf die Version zurück, die Sie bereits ausführen – kein erzwungenes Upgrade, keine erzwungene Migration. Beginnen Sie hier mit dem Patchen.
