Veraltete Software in Container-Images gefährdet deutsche Unternehmen

Kubernetes ist in vielen deutschen Unternehmen längst gesetzt. Doch ausgerechnet dort, wo Anwendungen heute besonders schnell entwickelt, verteilt und skaliert werden, entsteht eine schwer sichtbare Sicherheitslücke: veraltete Software in Container-Images. Was bisher oft unter dem Radar klassischer Schwachstellenscanner blieb, könnte für Unternehmen zum entscheidenden Risikofaktor in Cloud-native-Umgebungen werden.

Abhinav Mishra, Director, Product Management, TotalCloud Kubernetes and Container Security bei Qualys ordnet die Gefahr ein.

Container-Technologien haben sich vom Spezialthema zum Standard moderner IT-Infrastrukturen entwickelt. Immer mehr Unternehmen betreiben geschäftskritische Anwendungen in Kubernetes-Clustern, automatisieren Deployments über CI/CD-Pipelines und setzen auf skalierbare Cloud-native-Architekturen. Der Vorteil: Geschwindigkeit, Flexibilität und Effizienz. Der Nachteil: Die Transparenz über die tatsächlich eingesetzte Software wird komplexer.

Besonders kritisch ist eine Risikoklasse , die in vielen Sicherheitsprozessen noch zu wenig Beachtung findet: Software, die ihr Support-Ende erreicht hat. Dazu gehören End-of-Life- oder End-of-Support-Komponenten wie veraltete Betriebssystem-Pakete, nicht mehr gepflegte Runtimes, abgekündigte Frameworks oder Open-Source-Bibliotheken, die weiterhin in Container-Images enthalten sind.

Warum klassische Schwachstellenscanner nicht ausreichen

Viele Unternehmen verlassen sich beim Schutz ihrer Container-Umgebungen auf klassische Image-Scans. Diese erkennen bekannte Schwachstellen, etwa CVEs, und liefern Hinweise auf Patches oder Updates. Doch sie beantworten nicht immer die entscheidende Frage: Welche Software-Komponenten werden künftig gar keine Sicherheitsupdates mehr erhalten?

Genau hier entsteht der sogenannte Lifecycle-Blindspot. Eine Komponente kann heute noch keine bekannte kritische Schwachstelle enthalten, morgen aber zum Risiko werden, weil der Hersteller oder die Community keine Updates mehr bereitstellt. In klassischen IT-Umgebungen lässt sich solche Software häufig über Asset-Management-Systeme identifizieren. In Cloud-native-Architekturen ist das deutlich schwieriger.

Denn kritische Software steckt nicht nur auf Servern oder Endgeräten. Sie liegt tief in Container-Images verborgen, wird über Build-Prozesse erzeugt, in Registries abgelegt und anschließend über Kubernetes in unterschiedliche Cluster, Namespaces und Workloads ausgerollt. Ein einzelnes veraltetes Basis-Image kann sich so unbemerkt in vielen Anwendungen wiederfinden.

Veraltete Container-Images werden zur multiplizierten Angriffsfläche

Das Problem verschärft sich durch die Wiederverwendung von Images. Ein nicht mehr unterstütztes Basis-Image bleibt selten auf einen einzelnen Dienst beschränkt. Es wird kopiert, erweitert, in neue Anwendungen integriert und über Teams hinweg weiterverwendet. Dadurch entsteht eine Angriffsfläche, die sich mit jeder neuen Bereitstellung vergrößert.

Für Sicherheitsteams wird es damit schwieriger, den tatsächlichen Umfang des Risikos zu erkennen. Welche Workloads laufen mit veralteter Software? Welche davon sind internetnah? Welche unterstützen geschäftskritische Prozesse? Und welche Systeme müssen zuerst aktualisiert oder ersetzt werden?

Diese Priorisierung wird noch wichtiger, weil Angreifer zunehmend automatisiert vorgehen. KI-gestützte Angriffswerkzeuge können Softwareinventare analysieren, veraltete Komponenten identifizieren und potenzielle Einfallstore miteinander kombinieren. Was für Verteidiger nach mühsamer Inventarisierung klingt, kann auf Angreiferseite zunehmend automatisiert erfolgen.

Qualys erweitert EOL/EOS-Erkennung auf Container und Kubernetes

Qualys adressiert diese Lücke mit einer Erweiterung seiner CSAM-Plattform, dem CyberSecurity Asset Management. Die EOL/EOS-Softwareerkennung wird auf Container-Images und Kubernetes-Workloads ausgeweitet. Damit sollen Unternehmen nachvollziehen können, welche nicht mehr unterstützten Betriebssysteme, Runtimes, Pakete und Bibliotheken in ihren Container-Images enthalten sind.

Der Ansatz ergänzt klassisches Image Scanning, ersetzt es aber nicht. Während CVE-Scans bekannte Schwachstellen sichtbar machen, zeigt die Lifecycle-Erkennung, welche Komponenten aus dem Wartungs- und Update-Zyklus gefallen sind oder bald fallen. Für Security- und Plattform-Teams entsteht dadurch ein vollständigeres Bild der tatsächlichen Risiken in Cloud-native-Umgebungen.

Entscheidend ist dabei nicht nur die reine Erkennung einer veralteten Komponente. Relevant ist auch der Kontext: Wo wird das betroffene Image aktiv eingesetzt? In welchem Kubernetes-Cluster läuft es? Welcher Namespace ist betroffen? Handelt es sich um einen Test-Workload oder um eine produktive, geschäftskritische Anwendung? Erst diese Verbindung aus Softwareinventar, Laufzeitkontext und Kritikalität ermöglicht eine risikobasierte Priorisierung.

Warum das Thema für deutsche Unternehmen besonders relevant ist

Für deutsche Unternehmen ist veraltete Software in Container-Images nicht nur ein technisches Problem. Gerade in regulierten Branchen wie Finanzdienstleistungen, Gesundheitswesen, Industrie und kritischen Infrastrukturen wird Software-Lifecycle-Management zunehmend zur Compliance-Frage.

Regulatorische Vorgaben wie NIS2, DORA und das IT-Sicherheitsgesetz 2.0 erhöhen den Druck, IT-Risiken nachvollziehbar zu erfassen, zu bewerten und zu beheben. Wer Container-Umgebungen nicht vollständig in sein Asset- und Schwachstellenmanagement integriert, riskiert blinde Flecken im Audit — und ungepatchte Angriffsflächen in der Produktion.

Besonders gefährlich ist dabei die falsche Annahme, Container seien automatisch kurzlebig und deshalb weniger riskant. Zwar werden Container häufig neu gebaut und schnell ersetzt. Doch wenn die zugrunde liegenden Images auf veralteten Komponenten basieren, wird dieselbe Schwachstelle immer wieder neu ausgerollt.

Kubernetes-Sicherheit braucht Lifecycle-Transparenz

Die Sicherheitsfrage in Kubernetes-Umgebungen verschiebt sich damit. Es reicht nicht mehr aus, einzelne Schwachstellen punktuell zu scannen. Unternehmen müssen verstehen, welche Software sie tatsächlich betreiben, welche Komponenten noch aktiv unterstützt werden und welche Workloads aufgrund ihres Einsatzortes oder ihrer geschäftlichen Bedeutung priorisiert werden müssen.

EOL- und EOS-Erkennung in Container-Images wird dadurch zu einem wichtigen Baustein moderner Cloud-Security-Strategien. Sie hilft, Risiken früher zu erkennen, technische Schulden sichtbar zu machen und Sicherheitsentscheidungen stärker am tatsächlichen Betriebskontext auszurichten.

Für deutsche Unternehmen ist das ein Weckruf: Cloud-native Sicherheit endet nicht beim Kubernetes-Cluster und auch nicht beim CVE-Scan. Sie beginnt mit vollständiger Transparenz über jede Software-Komponente, die in Produktion läuft — auch dann, wenn sie tief im Container-Image verborgen ist.