Wie man Container im Produktivbetrieb modernisiert, um der ständigen CVE-Flut standzuhalten

Common Vulnerabilities and Exposures (CVE) ist ein öffentlich zugänglicher Katalog, in dem bekannte Sicherheitslücken in Software und Hardware unter eindeutigen Kennungen erfasst werden.

Im Jahr 2024 wurden mehr als 40.000 CVEs veröffentlicht, rund 38 % mehr als im Jahr 2023 (2024 CVE Data Review). Damit ist der Umgang mit Schwachstellen in Container-Images keine nebensächliche Aufräumarbeit mehr. Diese Schwachstellen sind ein Fluss, der die Kubernetes-Cluster überflutet und die Teams mit operativem Aufwand überschwemmt, während die tatsächliche Gefährdung unbemerkt bleibt.

Die Jagd nach jedem einzelnen CVE ist jedoch sinnlos, weil neue CVEs ständig veröffentlicht werden. Eine bessere Lösung ist es, ein zentrales Schwachstellenmanagementsystem aufzubauen, das als Damm gegen die CVE-Flut dient und eine kontrollierte Identifizierung, Priorisierung und Behebung von Schwachstellen ermöglicht.

Dieser Beitrag stellt verwendbare Ansätze für den Aufbau eines solchen Systems vor, das sich auf Hardened Images, überprüfbare Build-Provenienz, verbindliche Behebungs-SLAs, konsolidierte Berichterstattung sowie klare Richtlinien für Aktualisierungen und die Behebung von Schwachstellen stützt.

Die ständige CVE-Flut und warum Kubernetes sich wie ein Kampfplatz anfühlt

Container-Images haben den Bereich von Cloud-Native-Computing revolutioniert, da sie gegenüber virtuellen Maschinen eine schnellere, einfachere und kostengünstigere Möglichkeit bieten, Services auszurollen. Kubernetes hat dieses Modell weiterentwickelt, indem es die Verwaltung containerisierter Workloads in großem Maßstab ermöglicht. So weit, so gut. 

Für viele Teams ist Kubernetes jedoch längst kein sicherer Hafen mehr. Stattdessen hat sich der Betrieb von Containern auf der Plattform in einen Kampfplatz verwandelt, auf dem jeder Schwachstellenscan Hunderte von CVE-Meldungen hervorbringt.

Hier ist eine realistische Situation. Das Schwachstellendashboard meldet 1.000 CVEs in der gesamten Container-Flotte. Tickets vermehren sich, Releases werden verschoben, und die Entwickler verbringen eine ganze Woche damit, Schwachstellen im Code, den sie nicht selbst geschrieben haben, zu beheben. Beim nächsten Release beginnt alles von vorn. Mit der Zeit führt dieses ständige CVE-Rauschen dazu, dass die Entwickler die Warnmeldungen ignorieren.

Das liegt weder daran, dass die Entwickler schlechte Arbeit leisten, noch daran, dass die Scanner fehlerhaft arbeiten. Die Ursache liegt in der Architektur von Container-Images. Ein Container-Image besteht aus mehreren Schichten und enthält zahlreiche Komponenten: Betriebssystem-Pakete, Laufzeitumgebung (z. B. JVM für Java, Node.js Runtime für JavaScript), Systembibliotheken und Abhängigkeiten, Konfigurationsdateien. Jede Komponente kann einen Angriffspfad hinzufügen, durch veraltete Pakete, Abhängigkeiten ohne Sicherheitsupdates oder Basis-Images aus nicht vertrauenswürdigen Quellen. Erschwerend kommt hinzu, dass Software schnell altert. Was gestern als sicher galt, kann heute aufgrund neu entdeckter Schwachstellen verwundbar sein.

Es ist ein Teufelskreis: Was zum Zeitpunkt des Builds noch als sicher galt, kann später als verwundbar eingestuft werden, ohne dass eine einzige Codezeile geändert wurde. Der permanente Krisenmodus wird so zum Normalzustand.

Das bedeutet jedoch nicht, dass die Container im Produktivbetrieb von Schwachstellen durchsetzt sein müssen. Schwachstellen müssen behoben werden. Ein skalierbares Ziel ist jedoch nicht die Vollkommenheit im Sinne von null CVEs, sondern Kontrolle. Kontrolle bedeutet, dass keine Risiken unentdeckt oder unkontrolliert bleiben. Sie wissen jederzeit:

• welche Container-Images und Workloads im Produktivbetrieb eingesetzt werden,
• welche Schwachstellenmeldungen für die laufenden Workloads tatsächlich relevant sind,
• wer für ihre Bewertung und Behebung verantwortlich ist,
• welche Behebungsfristen beziehungsweise SLA (Service-Level-Vereinbarung) für Patches gelten.

Dies erfordert ein Umdenken bei den verwendeten Kennzahlen. Eine vollständige CVE-Freiheit im Produktivbetrieb lässt sich in der Praxis nicht durchsetzen. Durchsetzen lassen sich jedoch die lückenlose Nachverfolgbarkeit aller Artefakte, die ausschließliche Bereitstellung signierter Images und die Behebung ausnutzbarer Schwachstellen in kritischen Workloads innerhalb der festgelegten SLA-Fristen.

Sobald Sie auf diese Weise vorgehen und die Schwachstellenfunde bewerten, drängt sich folgende Frage auf:

Welche Komponenten verursachen die meisten CVE-Meldungen, und warum tritt das Problem immer wieder auf?

Für die meisten Unternehmen lautet die Antwort: nicht zentral verwaltete Basis-Images.

Hardened Images: Der wirkungsvollste Hebel zur Eindämmung der CVE-Flut

Ein Basis-Image bildet das Fundament eines Container-Images. Es enthält die benötigten Betriebssystemkomponenten, bei Bedarf eine Laufzeitumgebung und die Pakete, die von der im Container laufenden Anwendung gebraucht werden. In Unternehmensumgebungen verwenden Teams gewöhnlich verschiedene, auf bestimmte Anwendungsfälle zugeschnittene Basis-Images für die Container-Images, die sie bereitstellen. 

Falls Teams ihre Workloads auf beliebigen Basis-Images aufbauen, holen sie sich einen Wildwuchs an Schwachstellen in den Produktivbetrieb. Jedes Team verwendet ein anderes Basis-Image, häufig in einer anderen Version, mit einem eigenen Paketsatz und einem eigenen Patchzyklus. Das Ergebnis ist eine uneinheitliche Sicherheitslage und ein dauerhaft hoher Aufwand für die Behebung von Schwachstellen.

Die CVE-Flut lässt sich am schnellsten und einfachsten durch die Standardisierung von Basis-Images eindämmen. Genau dabei helfen gehärtete Container-Images, im Folgenden als Hardened Images bezeichnet. Sie reduzieren drastisch die Zahl der geerbten Schwachstellen und senken den Aufwand für die Behebung der verbleibenden Sicherheitsprobleme. 

Aber was verbirgt sich hinter diesem Begriff?

Hardened Images bringen minimale Angriffsfläche, proaktive Sicherheitsmaßnahmen, integrierte Provenienz und Verantwortlichkeit der Anbieter zusammen. Betrachten wir diese Merkmale nun im Einzelnen.

Minimale Angriffsfläche

Ein Hardened Image hat durch sein Design kaum bis gar keine bekannten CVEs und einen unveränderlichen Satz von Paketen und Komponenten, die für den Betrieb der Anwendung tatsächlich erforderlich sind. Container, die auf einem solchen Image basieren, starten daher mit möglichst wenigen bekannten Schwachstellen. Zugleich verhindert die Unveränderlichkeit des Images nachträgliche, nicht nachvollziehbare Änderungen am zugrunde liegenden Artefakt. 

Integrierte Provenienz

Softwareprovenienz bezeichnet überprüfbare Informationen über den Ursprung und den Erstellungsprozess eines Softwareartefakts. Sie dokumentiert, aus welchen Quellen, mit welchen Abhängigkeiten und auf welcher Build-Plattform das Artefakt erzeugt wurde.

Die Provenienz wird durch eine Software Bill of Materials (SBOM), die die enthaltenen Komponenten und deren Versionen auflistet, sowie durch eine kryptografische Signatur ergänzt. Mit der Signatur lässt sich überprüfen, ob das Artefakt aus der erwarteten Quelle stammt und seit seiner Signierung nicht manipuliert wurde.

Gemeinsam ermöglichen diese Informationen die Nachverfolgbarkeit von Softwareartefakten und erleichtern die Erfüllung regulatorischer Anforderungen sowie die Durchführung von Audits.

Verantwortlichkeit der Anbieter

Ein Hardened Image ist nicht einfach ein Artefakt, das Sie einmal herunterladen und vergessen. Es ist Teil einer kuratierten Familie von Basis-Images, die gemeinsame Eigenschaften haben: einen einheitlichen Härtungsstandard, überprüfbare Provenienz sowie die Verpflichtung des Anbieters, regelmäßig Sicherheitsupdates und Patches bereitzustellen.

Um diese Eigenschaften dauerhaft zu gewährleisten, muss jemand die Verantwortung für die Pflege der gesamten Image-Familie übernehmen. Genau das ist mit der Verantwortung des Anbieters gemeint.

Sie setzt voraus, dass der Anbieter die Basis-Images als kontinuierlich gepflegtes Produkt behandelt, einen festen Release-Zyklus einhält und SLAs für die Reaktion auf kritische Schwachstellen sowie deren Behebung festlegt. Das ermöglicht einen stabilen Patch-Rhythmus, auf den Anwendungsteams sich verlassen können, und erleichtert die Vereinheitlichung des Technologie-Stacks.

Es gibt mehrere Anbieter von Hardened Images, darunter BellSoft, Chainguard und Docker. Bei der Auswahl sollten Sie einen Anbieter bevorzugen, der nachweisliche Kompetenz in den Bereichen Betriebssystemsicherheit und Compliance besitzt und belastbare Garantien für die Softwarelieferkette bietet. Dazu gehören kryptografisch signierte Images, vollständige SBOMs, überprüfbare Provenienz, ein verlässlicher Patch- und Release-Zyklus sowie klare SLAs für die Reaktion auf kritische Schwachstellen und deren Behebung.

Prüfen Sie außerdem den Build-Prozess der Images. Vertrauenswürdige Anbieter erstellen Betriebssystemkomponenten und Laufzeitumgebungen aus überprüfbarem Quellcode. Auf diese Weise reduzieren sie die Abhängigkeit von nicht nachvollziehbaren Binärartefakten aus Drittquellen und ermöglichen eine bessere Kontrolle über enthaltene Komponenten. 

Die Migration auf gehärtete Basis-Images ist ein großer Schritt vorwärts. Dabei ersetzen Sie einen unkontrollierten Wildwuchs aus Ad-hoc-Basis-Images durch ein einheitliches, kontrolliertes und überprüfbares Fundament. Auf dieser Grundlage können Sie ein Schwachstellenmanagementsystem mit verbindlichen Richtlinien für zugelassene Images, regelmäßigen Scans und automatisierten Rebuilds aufbauen.

Im nächsten Abschnitt bauen wir ein solches System Schritt für Schritt auf.

Von Hardened Images zum geregelten Schwachstellenmanagement

Hardened Images weisen kaum oder gar keine bekannten CVEs auf, sofern sie regelmäßig erneuert werden. Ihre Umgebung umfasst jedoch auch Anwendungsabhängigkeiten und die Orchestrierungsplattform. Jedes Artefakt kann Schwachstellen enthalten. Das Ziel ist aber weiterhin nicht die vollständige CVE-Freiheit, sondern die Kontrolle der Risiken.

Wie kann man dieses Ziel erreichen?

Standardisierung auf ausgewählte Basis-Images

Ohne Standardisierung lässt sich kein robustes Schwachstellenmanagementsystem aufbauen.

Standardisierung bedeutet, dass ein Unternehmen eine begrenzte Auswahl von Hardened Images verwendet, die vom Plattformteam geprüft und freigegeben wurden. Die Build-Richtlinien erlauben nur diese Images als Basis für Anwendungen. Auf diese Weise können Sie einfach prüfen, welche Images im Produktivbetrieb eingesetzt werden. Außerdem können Rebuilds automatisch ausgelöst werden, sobald aktualisierte Versionen der Basis-Images verfügbar sind.

Gewährleistung unveränderlicher Builds durch Digest-Pinning

Hardened Images erschweren nachträgliche Änderungen am laufenden Container, indem sie beispielsweise auf Paketmanager und Download-Werkzeuge verzichten. Dies allein gewährleistet noch keinen deterministischen Build-Prozess. Deswegen muss Standardisierung zusammen mit Determinismus eingeführt werden.

Ein deterministischer Build-Prozess bedeutet, dass bei identischen Eingaben ein bis auf das letzte Byte identisches Ergebnis erzeugt wird. Dadurch können Teams sicherstellen, dass sie genau die Software ausliefern, die sie zuvor überprüft haben. Zugleich lassen sich Abweichungen zwischen einzelnen Builds leichter erkennen, z. B. wenn das Artefakt manipuliert, eine Abhängigkeit aktualisiert oder eine neue Upstream-Version veröffentlicht wurde.

Der beste Weg zu deterministischen Builds besteht darin, alle Build-Eingaben zu pinnen:

• Toolchain: Compiler, Laufzeitumgebung und Paketmanager
• Build-System: Container-Images, CI-Runner und Plug-ins
• Betriebssystem- und Systemabhängigkeiten
• Basis-Images

Basis-Images sind in der Regel auf Versions-Tags gepinnt. Versions-Tags sind zwar bequem, können aber langfristig auf einen anderen Image-Inhalt verweisen. Dadurch besteht die Gefahr, dass im Produktivbetrieb unbeabsichtigt eine andere Softwareversion eingesetzt wird. Eine bewährte Vorgehensweise ist daher das Pinning auf einen unveränderlichen Digest.

Wenn die Builds deterministisch werden, wird der Build-Prozess reproduzierbar, nachvollziehbar und auditierbar.

Erzeugung von SBOMs und Provenienzdateien bei jedem Build

Schwachstellenscans ohne Bestandsaufnahme erzeugen viel Rauschen. Es ist dann schwer nachzuvollziehen, welche Dateien und Schwachstellen zu welchen Komponenten gehören, während kritische Sicherheitsprobleme übersehen werden können. 

Die Software Bill of Materials (SBOM) kann mit der Lösung dieses Problems helfen. Sie enthält Informationen über Bibliotheken, Module und sonstige Softwarekomponenten, die zur Erstellung eines Artefakts verwendet wurden. Bei jedem Build sollte eine SBOM erzeugt werden, in der die im Image enthaltenen Komponenten und ihre Versionen aufgeführt sind.

Die SBOM kann zusammen mit den Anwendungsbinärdateien in einem Artefakt-Repository, zusammen mit den Container-Images in einer Container-Registry oder in einer speziellen SBOM-Managementplattform wie Dependency Track gespeichert werden. Das Wichtigste ist, dass sie versioniert, nachvollziehbar und für Audits und Schwachstellenscans zugänglich ist.

Provenienz geht einen Schritt weiter, indem sie ein Softwareartefakt mit seinem Build-Prozess verknüpft. Provenienzdateien enthalten unter anderem Angaben zur Identität des Build-Systems, zum verwendeten Commit im Quellcode-Repository sowie zum Ablauf des Builds.

SBOMs und Softwareprovenienz werden von bestimmten regulatorischen Anforderungen vorausgesetzt und können daher erforderlich sein, um Audits erfolgreich zu bestehen. Sie bieten jedoch mehr als bloße Einhaltung von Vorschriften:

• Wenn ein neues CVE veröffentlicht wird, kann man schnell das Ausmaß der Auswirkungen bewerten.
• Die Herkunft von Schwachstellen lässt sich eindeutig zuordnen: Welche stammen aus dem Basis-Image, und welche wurden durch die Anwendung oder ihre Abhängigkeiten eingebracht?

Signierung und Überprüfung von Artefakten bei der Bereitstellung

Nachdem die SBOM und Provenienzdateien erzeugt wurden, sollten die Images kryptografisch signiert werden, damit man überprüfen kann, ob sie aus einer vertrauenswürdigen Quelle stammen und seit der Signierung nicht verändert wurden.

Signaturen und Softwareattestierungen helfen, die Authentizität und Integrität eines Artefakts zu bestätigen und die Bereitstellung manipulierter oder nicht autorisierter Software zu verhindern. Die Überprüfung der Signaturen vor dem Deployment ermöglicht zugleich die automatisierte Durchsetzung von Richtlinien. Der Cluster akzeptiert nur Artefakte, die aus einer vertrauenswürdigen Softwarelieferkette stammen, auf zugelassenen Basis-Images beruhen und über die erforderlichen SBOM- und Provenienzdateien verfügen.

Der ganze Workflow kann auf folgende Weise aufgebaut werden:

• Für jedes Image werden eine SBOM und Provenienz erzeugt.
• Die SBOM und die Provenienzdateien werden signiert und dem Digest des Container-Images zugeordnet. Das Open-Source-Tool Syft kann beispielsweise eine SBOM erzeugen. Cosign kann diese in eine in-toto-Attestierung einbetten und kryptografisch signieren. Die Attestierung wird als JSON-Datei gespeichert und kann dem Container-Image in der Container-Registry beigefügt werden.
• Vor dem Deployment werden die Signaturen und Attestierungen überprüft.

Aus dieser Überprüfung können drei mögliche Ergebnisse folgen:

Zulassen:

Die Signaturen und die Attestierung sind gültig, die Images erfüllen die geltenden Richtlinien und können bereitgestellt werden.

Quarantäne oder manuelle Prüfung:

Es wurden Abweichungen festgestellt, die untersucht werden müssen. Dazu gehören beispielsweise nicht überprüfbare Signaturen, veraltete SBOMs oder mittelschwere Probleme mit kompensierenden Kontrollmaßnahmen.

Ablehnen:

Das Image verstößt gegen die geltenden Richtlinien oder stellt ein hohes Risiko dar. Mögliche Gründe sind eine fehlende Signatur, eine falsche Identität oder ein nicht vertrauenswürdiger Aussteller, eine fehlende oder ungültige Attestierung, eine Abweichung zwischen der attestierten Quelle und dem referenzierten Quellcode-Commit oder kritische Schwachstellen, für die Patches verfügbar sind, die aber nicht eingespielt wurden.

Einführung kontinuierlicher Schwachstellenscans

Ein einmaliger Schwachstellenscan während des Builds ist nicht genug. Neue CVEs werden ständig veröffentlicht, und darüber hinaus bestehen Sicherheitsrisiken, die nicht mit bekannten Schwachstellen zusammenhängen. Dazu gehören beispielsweise weitreichende Berechtigungen, privilegierte Ausführung und offengelegte Secrets.

Deswegen sollte man einen kontinuierlichen Scanprozess einführen, damit Sicherheitsrisiken in bereits erstellten Artefakten und laufenden Workloads innerhalb kurzer Frist erkannt, bewertet und behoben werden können.

Die Scans sollten folgende Bereiche umfassen:

• CVEs in Basis-Images und Anwendungsabhängigkeiten,
• Unsichere Konfigurationen und riskante Standardeinstellungen, etwa fehlende Ressourcenlimits oder ein nicht aktiviertes seccomp-Profil,
• Verdächtiges Laufzeitverhalten, beispielsweise ungewöhnliche Systemaufrufe.

Nachdem feststeht, was überprüft werden soll, stellt sich die nächste Frage: Wann sollte gescannt werden? Verschiedene Scanner decken unterschiedliche Risikobereiche ab. Daher wäre es besser, mehrere Tools in verschiedenen Phasen des Softwarelebenszyklus einzusetzen: 

• Bei jedem CI-Build, um kritische Probleme, wie ausnutzbare Schwachstellen sowie fehlende SBOMs oder Provenienz, frühzeitig zu erkennen und den Build daraufhin zu blockieren. 
• Beim Push eines Images in die Registry, um Attestierungen und Signaturen zu überprüfen.
• Regelmäßig anhand der SBOM, um neu veröffentlichte CVEs, die sich auf die eingesetzten Workloads auswirken, zu erkennen.
• Kontinuierlich in der Laufzeitumgebung, um verdächtiges Verhalten in laufenden Workloads zu erkennen.

Ohne festgelegtes Bewertungsschema sind die Scannerergebnisse jedoch nur Rauschen. Die Risikobewertung einer Schwachstelle kann sich an folgenden Fragen orientieren:

• Welche Komponenten sind von der Schwachstelle betroffen?
• Ist diese Schwachstelle ausnutzbar?
• Gibt es einen Patch?
• Ist die betroffene Komponente öffentlich erreichbar?
• Wie groß ist der mögliche Auswirkungsradius?

Anhand der Antworten lassen sich die Schwachstellenfunde einer von drei Behandlungsmaßnahmen zuordnen: sofort beheben, mit dem nächsten Update beheben oder eine zeitlich begrenzte Ausnahme genehmigen.

Skalierbare Verteilung von Patches durch Rebuilds und Rolling Updates

Nach Standardisierung, Bestandsaufnahme, Scans und Risikobewertung erreichen wir die letzte Stufe eines vollständigen Schwachstellenmanagements, nämlich die tatsächliche Schwachstellenbehebung. 

Ziel dieser Stufe ist es, die Ergebnisse der Risikobewertung in einen verlässlichen und wiederholbaren Prozess für den Produktivbetrieb zu überführen. Dazu gehören der Rebuild betroffener Artefakte, ihre sichere Bereitstellung sowie der Nachweis, dass die Schwachstellen tatsächlich behoben wurden. Mit anderen Worten: die skalierbare Verteilung von Patches.

Viele Unternehmen patchen jeden Service einzeln. In Kubernetes-Umgebungen mit vielen Workloads ist dieser Ansatz jedoch nicht skalierbar. Der Patching-Prozess muss daher in die Softwarelieferkette integriert werden. Die Updates von Basis-Images sollten Rebuilds von betroffenen Container-Images automatisch auslösen. Diese Container-Images sollten dann durch kontrollierte Rollouts schrittweise in den Kubernetes-Clustern bereitgestellt werden.

Der Update-Zyklus kann zwei Pfade umfassen:

• Regelmäßige Updates, die wöchentlich oder in einem anderen festgelegten Intervall durchgeführt werden und nur minimale Änderungen enthalten. Sie können mit Basis-Image-Updates gebündelt werden.
• Notfall-Updates, die durchgeführt werden, wenn aktiv ausgenutzte oder besonders schwerwiegende Schwachstellen veröffentlicht und in den eingesetzten Workloads erkannt werden.

Sobald der Anbieter ein Basis-Image aktualisiert, sollte für jeden Service, der dieses Basis-Image verwendet, automatisch der folgende Prozess ausgelöst werden:

• Das Container-Image der Anwendung wird gegen das aktuelle Basis-Image neu gebaut.
• Die SBOM und Provenienzdateien werden erneut erzeugt.
• Das neue Artefakt wird signiert.
• Das Container-Image wird erneut gescannt.
• Anschließend wird es mithilfe eines Canary-Rollouts schrittweise bereitgestellt.

Sobald die neu gebauten, gescannten und signierten Images in der Registry sind, werden sie clusterübergreifend ausgerollt. Die Bereitstellungsstrategie sollte sich nach der Kritikalität und Exposition des jeweiligen Workloads richten, beispielsweise:

• eine progressive Bereitstellung mit Canary- oder stufenweisen Rollouts für besonders kritische Services,
• standardmäßige Rolling Updates für weniger kritische Services,
• ein automatischer Rollback, wenn sich der Zustand oder die Stabilität eines Workloads verschlechtert.

Durch regelmäßige Aktualisierungen der Basis-Images bleiben die laufenden Services frei von bekannten kritischen Schwachstellen. Auch die Behebungszeit für kritische Sicherheitslücken verkürzt sich auf wenige Stunden oder Tage, und die Teams müssen weniger Zeit darauf verwenden, einzelnen CVE-Meldungen hinterherzulaufen.

Fazit

Die CVE-Flut wird nie aufhören, aber Container-Images im Produktivbetrieb müssen nicht darin untergehen. Eindämmen lässt sich die Flut mit dem Ziel, keine unkontrollierten Risiken zuzulassen: durch die Standardisierung auf Hardened Images, deterministische und überprüfbare Builds und kontinuierliche Scans von Artefakten und Kubernetes-Clustern.

Die skalierbare Verteilung von Patches schließt den Kreislauf. Aktualisierungen von Basis-Images lösen dabei automatisierte Rebuilds aus. Anschließend werden die signierten und gescannten Images anhand ihrer Digests sicher und kontrolliert in den Clustern ausgerollt. So wird die Reaktion auf Schwachstellen vom ständigen Kampf zur routinemäßigen Wartungsaufgabe.