Eine Brücke bleibt bei einem festgelegten Inspektionsplan fünfzig Jahre lang in Betrieb, wird während dieser Zeit Belastungsprüfungen unterzogen und gewartet. Ein Düsentriebwerk wird jahrzehntelang in derselben Bauart unter ständiger behördlicher Aufsicht eingesetzt. In den meisten Bereichen des Ingenieurwesens ist eine stabile, bewährte Konstruktion in Verbindung mit aktiver Wartung das Ziel. Neuere Konstruktionen werden weitaus kritischer geprüft, da sie noch nie wirklich auf Herz und Nieren getestet wurden.
Aus irgendeinem Grund gilt in der Softwareentwicklung jedoch das Gegenteil. Die neueste Version wird als die sicherste angesehen. Und dieser Instinkt hat sich in der Vergangenheit schon oft als Bumerang erwiesen. In zwei bestimmten Versionen von xz-utils, die Versionen 5.6.0 und 5.6.1, wurden von einem Eindringling eingeschleust, der zwei bis drei Jahre lang daran gearbeitet hatte, sich die Berechtigung zur Veröffentlichung zu verschaffen. Wer noch die ältere 5.4-x-Reihe nutzte, war zu keinem Zeitpunkt gefährdet, aber jeder, der die neueste Version installiert hatte – was Sicherheitsteams normalerweise empfohlen wird –, nutzte einen SSH-Zugang mit Hintertür. Die CISA empfahl daraufhin, ein Downgrade statt eines Upgrades durchzuführen.
Wir haben bereits zuvor in dem, was wir als „Die Upgrade-Falle„… dass das Patchen unmittelbar nach Bekanntwerden einer CVE eine falsche Sparmaßnahme ist; man hat die Wahl zwischen einem Stillstand und der Akzeptanz der Änderungen, die mit dem Patch einhergehen.“ xz-utils zeigt uns die Kehrseite derselben Medaille. Das Bleiben war der sichere Weg, und die neueste Veröffentlichung war die Falle.
Eine Möglichkeit, dies zu überprüfen, besteht darin, ein Sicherheitsteam nach der Anzahl der offenen CVEs zu fragen – diese Frage lässt sich in der Regel schnell beantworten. Fragt man jedoch, warum ein bestimmtes Paket oder ein bestimmtes „ container “-Image in der aktuellen Version läuft, erhält man höchstwahrscheinlich die Antwort: „Keine Ahnung“. So ist es eben, oder? Meistens hängt es davon ab, was zum Zeitpunkt des Projektstarts verfügbar war, und ein Upgrade erschien als mehr Aufwand, als es wert war. Geht man noch einen Schritt weiter und fragt nach einer schriftlichen Dokumentation dieser Entscheidung, erhält man wahrscheinlich eine noch schärfere Antwort nach dem Motto:„Warum sollten wir das überhaupt tun?“
Wo läuft es also schief?
Oft wird Ingenieuren suggeriert, dass ein „ container “-Image oder -Paket riskanter wird, wenn die Versionsnummer veraltet ist. Aber die xz-utils Dieses Beispiel beweist, dass dies nicht zutrifft; die ältere Version war sicher, da noch keine Schadsoftware in sie eingedrungen war und die Teams, die sie einsetzten, nicht sofort nach der Veröffentlichung auf die neueste Version umgestiegen waren. Natürlich besteht die Möglichkeit, dass viele Teams einfach noch nicht dazu gekommen sind, das Update durchzuführen, es aber vorhatten. Das ist immer noch besser, als nicht zu wissen, welche Version man einsetzt oder warum – und genau das ist hier das eigentliche Versagen.
Stattdessen müssen Teams bedenken: Wenn sie über eine Version einer Bibliothek verfügen, die getestet, verstanden und als vertrauenswürdig eingestuft wurde, liegt ein echter Mehrwert darin, diese stabil zu halten. Die Überwachung beginnt in dem Moment, in dem ein Entwickler, ein Agent oder eine Build-Pipeline ein Basis-Image von „ container “ oder ein Open-Source-Paket anfordert, indem diese vor dem Einbringen in die Umgebung geprüft werden. Dies ist die erste Entscheidung in einer Kette von Entscheidungen, die getroffen werden.
Ein Upgrade ist ebenfalls eine Entscheidung
Irgendwann wird eine neue Version erscheinen, aber das Beheben einer CVE bedeutet, dass man auch alles andere akzeptiert, was in dieser Version enthalten ist. Dazu gehören Dinge wie transitive Abhängigkeiten, geänderte Standardeinstellungen und Codepfade, die niemand im Team gelesen hat. Meistens ist dieses Risiko nicht erkennbar und es geht nichts schief. Aber – und das ist ein großes Aber – es kann schiefgehen. lodash Im Jahr 2026 gab es eine Sicherheitslücke durch willkürliche Code-Injektion, von der alle veröffentlichten Versionen betroffen waren. Als der Fix schließlich mit Version 4.18.0 veröffentlicht wurde, kam es sofort zu Fehlern, da der Patch eine andere interne Funktion einfügte, die nie importiert worden war, was dazu führte, dass reale Projekte innerhalb eines Tages ausfielen.
npm hat die Version vollständig als veraltet eingestuft und die Nutzer aufgefordert, wieder auf lodash 4.17.21 Stattdessen hatte die Kompatibilitätsänderung nichts mit der Sicherheitslücke selbst zu tun, sondern es handelte sich um einen Fehler bei der Paketierung, der zusammen mit dem Sicherheitspatch geliefert wurde. Der eigentliche Patch wurde mit Version 4.18.1 bereitgestellt.
Keine der zur Debatte stehenden Optionen war tatsächlich sicher. Ein Upgrade auf 4.18.0 führte sofort zu Fehlern beim Build. Ein Verbleib bei 4.17.21 ließ die Sicherheitslücke offen, während jede Version vor 4.18.0 weiterhin ausnutzbar blieb. Einige Teams führten gezielt ein Downgrade zurück auf 4.17.x durch, um den fehler escape n Build zu beheben, und tauschten dabei einen funktionierenden Build gegen einen aktiven Code-Injection-Pfad ein, ohne sich unbedingt bewusst zu sein, dass sie genau diesen Kompromiss eingegangen waren.
In diesem Fall waren die Teams in der besten Position diejenigen, die wussten, ob ihre eigene Anwendung die betroffene _ überhaupt aufrief.template einen Weg mit nicht vertrauenswürdigen Eingaben wählen und dieses tatsächliche Risiko gegen die fehlerhafte Alternative abwägen, anstatt sich standardmäßig für eine der beiden Optionen zu entscheiden, ohne zu wissen, was sie das tatsächlich kostet.
Die Sicherheitslücke beheben, ohne alles drumherum zu ersetzen
Das Backporting verändert die Situation. Dabei wird die spezifische Korrektur für die jeweilige Sicherheitslücke auf die bereits ausgeführte Version angewendet, anstatt alle anderen Komponenten mit einzubeziehen, die im Upstream-Release enthalten waren. Wendet man dies auf ein „ container “-Image an, wird die CVE behoben, ohne dass ein neues Basis-Image erzwungen wird. Wendet man dies auf ein Paket an, wird dieselbe Korrektur vorgenommen, ohne dass ein erzwungener Sprung zur neuesten Version erforderlich ist – genau der Sprung, der bei laufenden Projekten zu Problemen geführt hat. lodash 4.18.0. Sie können das Sicherheitsproblem beheben, ohne alles drumherum zu verändern.
Ein „ SBOM “ sollte sich seinen Platz verdienen und nicht einfach nur existieren.
Ein SBOMwird, wie so viele Dokumente im Zusammenhang mit dem „ compliance “, oft nur einmal erstellt und dann abgelegt. Daraus geht hervor, was sich an dem Tag, an dem jemand den Bericht erstellt hat, im System befand. Doch die SBOM kann weitaus mehr für Ihre Sicherheitslage tun als das. Er kann als vertrauenswürdige Software-Baseline dienen und Ihnen helfen, diese Baseline kontinuierlich zu verwalten. Dazu müssten Sie sicherstellen, dass er auf dem neuesten Stand gehalten und regelmäßig auf neue Sicherheitslücken überprüft wird, sobald diese bekannt werden. Das ist für mich das deutlichste Zeichen dafür, dass ein Unternehmen die von ihm genutzte Software weiterhin im Blick behält, anstatt sich auf dem Bestehenden auszuruhen.
Wir möchten, dass die „ SBOM “ nicht nur ein Inventar oder ein Artefakt der „ compliance “ bleibt. Sie sollte eine geregelte, aktiv gepflegte Schnittstelle sein.
Was muss sich also ändern?
All dies sind Entscheidungen, die getroffen werden müssen. Bei einigen geht es um eine bestimmte Softwarekomponente zu einem bestimmten Zeitpunkt, wie zum Beispiel die Bewertung einer Anfrage, das Festlegen einer Version und das Backporting anstelle eines erzwungenen Upgrades. Bei anderen, wie zum Beispiel der Frage, ob man eine „ SBOM “ auf dem neuesten Stand hält, geht es um die bestehenden Prozesse. Jede dieser Entscheidungen ist im Grunde eine Entscheidung darüber, wem man vertraut.
Am einfachsten ist es, alles so zu lassen, wie es ist, denn „es funktioniert“. Aber „es funktioniert“ stimmt doch nicht wirklich, oder? Nur weil etwas funktioniert, heißt das noch lange nicht, dass es immer funktionieren wird, dass es die sicherste Vorgehensweise ist oder dass es die beste Art ist, die Dinge zu handhaben.
Aus unserer Sicht wäre der proaktivste und sicherheitsbewussteste Ansatz, Änderungen bereits am Eingang zu kontrollieren – also Pakete zu prüfen, bevor ein Entwickler, ein Agent oder ein Build-System sie nutzt. Auf dieser Grundlage sollten Sie die Freiheit haben, proaktiv zu entscheiden, was hereinkommt, vertrauenswürdige Komponenten festzulegen, diese zu pflegen und nur dann zu ändern, wenn es einen Grund dafür gibt.
An einer Version festzuhalten sollte nicht bedeuten, weiterhin angreifbar zu sein. Aikido Bibliotheken portiert den Fix auf die Version, die Sie bereits nutzen – kein erzwungenes Upgrade, keine erzwungene Migration. Beginnen Sie mit dem Patchen hier.
