Dein Blog zum Thema digitales Business

Du scannst dein Image, der Scanner findet nichts Kritisches, und trotzdem sitzt du auf einem Risiko, das mit jedem Tag wächst. Der Grund hat nichts mit einer übersehenen CVE zu tun. Er liegt darin, dass der Hersteller irgendwann aufhört, überhaupt noch Patches zu schreiben.

Was End of Life technisch bedeutet

Jede Sprach-Runtime und jede Linux-Distribution hat ein festes Support-Ende. Ab diesem Datum bekommt eine Version keine Sicherheitsupdates mehr, unabhängig davon, wie schwerwiegend eine neu entdeckte Lücke ist. Ein paar Beispiele mit festen Terminen: Python 3.9 ist seit dem 31. Oktober 2025 ohne Sicherheitssupport, Node.js 20 (Iron) ist seit dem 30. April 2026 ohne Sicherheitssupport, Debian 11 (Bullseye) erreichte sein Support-Ende am 31. August 2026, fünf Jahre nach der Erstveröffentlichung, und Ubuntu 20.04 LTS (Focal Fossa) verlor den Standard-Support bereits am 31. Mai 2025. Alpine-Linux-Release-Branches sind im Hauptrepository standardmäßig auf zwei Jahre Unterstützung angelegt. Diese Termine stehen lange vorher fest, meist Jahre im Voraus, und sind öffentlich nachlesbar, etwa über endoflife.date oder die jeweilige Projekt-Ankündigung des Herstellers.

Warum das etwas anderes ist als eine bekannte CVE

Der Beitrag Vulnerability Management: vom CVE-Report zur Priorisierung behandelt den Fall, in dem eine Schwachstelle bekannt, bewertet und mit einem Fix versehen ist. Die eigentliche Arbeit dort ist Priorisierung. Bei einer End-of-Life-Runtime gibt es diesen Fix grundsätzlich nicht mehr. Wird nach dem Stichtag eine neue Lücke in Python 3.9 oder Debian 11 gefunden, bleibt sie offen, dauerhaft, weil niemand mehr dagegen patcht. Das ist kein Backlog-Posten, das ist ein strukturell fehlender Reparaturweg.

Warum ein Image-Scan das nicht auffängt

Der Beitrag Container-Images absichern: Was beim Scannen wirklich zählt beschreibt die Scan-Mechanik: ein Werkzeug prüft ein Image gegen bekannte Schwachstellen-Datenbanken und meldet Treffer. Das funktioniert für den Moment der Prüfung. Es sagt aber nichts darüber, ob die Basis dieses Images in drei Monaten noch versorgt wird. Ein Alpine- oder Debian-Basisimage kann heute sauber durch den Scan laufen und trotzdem auf einer Version stehen, deren Support-Fenster in absehbarer Zeit schließt. Der Scan ist eine Momentaufnahme, das Lifecycle-Ende ist ein Termin in der Zukunft, den kein CVE-Scanner kennt.

Das eigentliche Risiko ist die Unsichtbarkeit

Ein End-of-Life-Zustand meldet sich nicht von selbst. Der Build läuft weiter, das Image lässt sich weiter bauen und deployen, nichts schlägt rot aus. Sichtbar wird das Problem erst rückwirkend: wenn eine kritische Lücke auftaucht, für die es keinen Patch mehr gibt, oder wenn eine Migration unter Zeitdruck passieren muss, weil sie über Monate liegen geblieben ist. Je mehr Basisimages und Sprachversionen in einer Pipeline im Umlauf sind, gerade bei gewachsenen Microservice-Landschaften, desto eher verliert jemand den Überblick, welche Version wann ausläuft.

Warum Versionen trotzdem liegen bleiben

Der häufigste Grund ist banal: ein Dockerfile pinnt eine Basisversion, weil sie beim ersten Aufsetzen funktioniert hat, und niemand fasst die Zeile danach noch an, solange der Build grün bleibt. Ein Upgrade der Sprach-Runtime kostet Zeit und Testaufwand, ein ausbleibender Patch macht sich zunächst nicht bemerkbar. Genau dieses Ungleichgewicht sorgt dafür, dass End-of-Life-Versionen in Pipelines länger überleben, als es irgendjemand beabsichtigt hat.

Lifecycle-Tracking statt einmaliger Prüfung

Der Unterschied zur reaktiven CVE-Behebung liegt im Zeitpunkt. Ein Inventar aller eingesetzten Basisimages und Sprach-Runtimes mit ihren jeweiligen Versionen ist der erste Schritt. Dagegen gehalten werden die veröffentlichten End-of-Life-Termine der Hersteller. Daraus lässt sich ein Kalender bauen: welche Version läuft wann aus, welche Migration muss wann beginnen, damit sie nicht erst nach dem Stichtag startet. Das ist kein einmaliges Audit, sondern ein laufender Abgleich, weil neue Versionen erscheinen und alte Termine näher rücken. Wer diesen Abgleich nicht führt, merkt vom Auslaufen einer Runtime meist erst dann etwas, wenn ein Sicherheitsvorfall oder eine Prüfung ihn dazu zwingt.

Das Leistungsspektrum ist gestaffelt und läuft über drei Felder: Implementation, also Delivery und Nachweis modulweise in die Pipeline einziehen, AI Governance, also Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten, und Maintenance, also die Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de