Warum Containersicherheit nur funktioniert, wenn die Plattform dafür verantwortlich ist

Containersicherheit hat sich endlich durchgesetzt.

Als Docker Ende 2025 gehärtete Container-Images ankündigte, komplett mit minimalen Angriffsflächen, Nicht-Root-Standardeinstellungen, kontinuierlicher CVE-Überprüfung und automatisierten Updates, war die Resonanz begeistert. Für Teams, die ihre eigene Infrastruktur verwalten, war dies ein echter Fortschritt. Sichere Standard-Container sind nicht mehr nur eine Nische oder teuer. Sie werden erwartet.

Dieser Moment hat jedoch auch ein Missverständnis offenbart, das in vielen Unternehmen immer noch besteht:

Verstärkte Images allein machen noch keine sichere Plattform aus.

In großem Maßstab ist Containersicherheit keine Funktion, die man einmalig einführt. Es handelt sich um eine fortlaufende operative Verantwortung, die irgendwo übernommen, automatisiert, getestet und geregelt werden muss. 

Die Frage ist nicht, ob Container gehärtet sind, sondern wer die Verantwortung dafür trägt, dass sie über einen längeren Zeitraum hinweg sicher bleiben.

Die Illusion eines „einzigen gehärteten Images”

Die Idee eines einzigen, gehärteten Basisimages ist verlockend. Ein Image, sorgfältig gesichert, kontinuierlich gepatcht und überall wiederverwendet. Einfach. Überprüfbar. Sicher.

Dieses Modell scheitert jedoch schnell in realen Produktivumgebungen.

Die meisten Teams verwenden mehr als eine Laufzeitumgebung. PHP, Python, Node.js, Java, Datenbanken, Caches. Jede Laufzeitumgebung unterstützt mehrere Versionen. Viele sind auf native Erweiterungen angewiesen, die für bestimmte Systembibliotheken kompiliert wurden. Wenn die falsche Abhängigkeit geändert wird, kommt es zu subtilen, kostspieligen Ausfällen der Anwendungen.

Hier kollidieren Sicherheit und Stabilität.

Wenn Sie ein Basisimage aggressiv aktualisieren, um die neuesten Patches zu erhalten, riskieren Sie, Workloads zu beschädigen. Wenn Sie Upgrades verzögern, um die Stabilität zu gewährleisten, erhöhen Sie das Risiko. Die meisten Anwendungsteams sind nicht in der Lage, diesen Kompromiss wiederholt und sicher zu bewältigen.

In großem Maßstab besteht das Problem nicht darin, ein Image zu härten.

Es geht darum, Hunderte von versionierten Images mit jeweils unterschiedlichen Kompatibilitätsbeschränkungen zu verwalten und gleichzeitig die Sicherheit aller Images zu gewährleisten.

Was sichere Container in großem Maßstab tatsächlich erfordern

Sobald Sie über einfache Beispiele hinausgehen, wird die Containersicherheit zu einer Aufgabe der Systemtechnik.

Eine sichere Plattform muss kontinuierlich Folgendes bewältigen:

• Mehrere Laufzeiten und Laufzeitversionen
• ABI-Kompatibilität für native Erweiterungen
• Paket-Updates und Sicherheitspatches auf Betriebssystemebene
• Kontrollierte Rollouts und Regressionstests
• Notfallmaßnahmen für kritische Schwachstellen
• Vorhersehbares, überprüfbares Update-Verhalten

Diese Arbeit ist repetitiv, unspektakulär und leicht zu unterschätzen. Sie kann nicht manuell erledigt werden und auch nicht ohne Risiko stückweise an Anwendungsteams delegiert werden.

Aus diesem Grund behandeln ausgereifte Plattformen die Containersicherheit als unsichtbare Infrastruktur. Etwas, das kontinuierlich im Hintergrund läuft, Komplexität absorbiert und sicher ausfällt.

Der Plattformansatz: Sicherheit ohne Heldentaten

Upsun hat diesen Ansatz von Anfang an verfolgt.

Anstatt ein einziges „goldenes” Container-Image zu pflegen, verwaltet Upsun Hunderte von Images über Laufzeiten und Versionen hinweg. Jedes Image wird unabhängig erstellt, aktualisiert und verfolgt, um die Kompatibilität zu gewährleisten und gleichzeitig Sicherheitsupdates zu erhalten.

Dies geschieht nicht durch Ad-hoc-Neuerstellungen oder manuelle Patches. Das System ist vollständig automatisiert und deklarativ. Paketversionen werden explizit definiert. Updates werden programmgesteuert erkannt. Images werden nur dann neu erstellt, wenn sich tatsächlich etwas ändert.

Meistens passiert nichts. Und genau darum geht es.

Sicherheit in großem Maßstab sollte langweilig sein. Sie sollte auf Automatisierung beruhen, nicht auf Wachsamkeit. Wenn Updates erforderlich sind, sollten sie durch eine vorhersehbare Pipeline fließen, die Korrektheit ebenso priorisiert wie Geschwindigkeit.

Warum der Testrhythmus wichtiger ist als die Patch-Geschwindigkeit

Sicherheitsdiskussionen konzentrieren sich oft darauf, wie schnell Patches angewendet werden. Geschwindigkeit ist wichtig, aber Geschwindigkeit ohne Kontrolle ist gefährlich.

Datenbank-Engines, Sprachlaufzeiten und Systembibliotheken sind keine austauschbaren Teile. Ein fehlerhaftes Update kann Daten beschädigen oder zu längeren Ausfällen führen. Dieses Risiko ist für eine Plattform, auf der Produktions-Workloads ausgeführt werden, inakzeptabel.

Aus diesem Grund trennt Upsun die Erstellung von Updates von deren Bereitstellung.

Images werden kontinuierlich überwacht und bei Änderungen an den Paketen neu erstellt. Die Bereitstellung in der Produktivumgebung erfolgt in einem gemessenen Rhythmus, wobei vor der Einführung umfassende Tests durchgeführt werden. Updates landen zunächst in internen Testumgebungen und werden dann sicher in die Produktivumgebung überführt.

Es gibt eine Ausnahme: kritische Schwachstellen, die aktiv ausgenutzt werden. In diesen Fällen kann die Plattform Updates über einen beschleunigten Pfad schnellstmöglich bereitstellen. Diese Fähigkeit besteht gerade deshalb, weil das normale System automatisiert und gut verstanden ist.

Das Ergebnis ist ein Gleichgewicht, das die meisten Teams allein nur schwer erreichen können:

• Schnelle Reaktion, wenn es wirklich darauf ankommt
• Stabilität und Vorhersehbarkeit in der übrigen Zeit

Was sich dadurch für Anwendungsteams ändert

Die praktischen Auswirkungen dieses Modells sind einfach, aber tiefgreifend.

Anwendungsteams müssen nicht mehr:

• CVE auf Betriebssystemebene verfolgen
• Basisimages neu erstellen
• die Einführung von Patches koordinieren
• sich um die Unterbrechung nativer Erweiterungen sorgen
• Entscheiden, wann Sicherheitsupdates „sicher genug” sind

Stattdessen sind die Verantwortlichkeiten klar verteilt:

• Die Plattform ist für Systempakete, Basisimages und Sicherheitsupdates zuständig
• Die Teams programmieren den Anwendungscode und die Abhängigkeiten auf Anwendungsebene

Diese Arbeitsteilung macht die Infrastruktur von einer ständigen Risikoquelle zu einer stabilen Grundlage.

Außerdem reduziert sie die kognitive Belastung. Ingenieure können sich auf die Bereitstellung von Features konzentrieren, anstatt zu bewerten, ob ein neuer OpenSSL-Patch ihre Laufzeitumgebung destabilisieren könnte.

Die eine Verantwortung, die Plattformen nicht für immer übernehmen können

Es gibt eine wichtige Grenze, die seriöse Plattformen ehrlich anerkennen.

Keine noch so umfangreiche Automatisierung kann Software sichern, die nicht mehr upstream gepflegt wird. Wenn eine Laufzeit- oder Betriebssystemversion das Ende ihrer Lebensdauer erreicht, werden keine Sicherheitsupdates mehr bereitgestellt. An diesem Punkt ist ein Upgrade die einzige sichere Option.

Upsun setzt diese Grenze bewusst durch. Images, die an nicht unterstützte Basissysteme gebunden sind, erhalten irgendwann keine Updates mehr. Dies ist keine Einschränkung der Plattform, sondern spiegelt die Realität wider.

Bei regelmäßigen Laufzeit-Upgrades geht es nicht darum, Neuheiten hinterherzujagen. Es geht darum, auf unterstützten Grundlagen zu bleiben, die tatsächlich gesichert werden können. Eine Plattform kann Upgrades sicherer und einfacher machen, aber sie kann aufgegebene Software nicht sicher machen.

Klare Grenzen schaffen Vertrauen.

Was die Ankündigung von Docker tatsächlich bestätigt

Die Entscheidung von Docker, gehärtete Images kostenlos und als open source anzubieten, ist gut für die Branche. Sie bestätigt, was erfahrene Plattformteams bereits wissen:

Containersicherheit kann nicht einfach nachträglich hinzugefügt werden. Sie erfordert Automatisierung, kontinuierliche Wartung und disziplinierte Einführung.

Genau dieses Modell wird bei Upsun seit Jahren in der Produktivumgebung eingesetzt, nicht als Feature-Launch, sondern als Notwendigkeit. Wenn Sie eine Plattform betreiben, die Tausende von Anwendungen über viele Laufzeiten hinweg hostet, ist manuelle Sicherheitsarbeit einfach nicht skalierbar.

Die wichtigste Arbeit ist nicht auffällig. Es ist die wiederholte, automatisierte Überprüfung von Paketen, die sorgfältige Neuerstellung von Images, das Testen von Pipelines und die kontrollierte Bereitstellung. Das ist es, was Systeme langfristig sicher hält.

Sicherheit als Eigenschaft der Plattform

Die eigentliche Erkenntnis ist nicht, wer es zuerst getan hat.

Es geht darum, wo Sicherheit hingehört.

Gehärtete Images sind wertvoll. Aber ohne eine Plattform, die Updates, Tests, Rollouts und Lebenszyklusmanagement übernimmt, verlagern sie die Verantwortung auf Teams, die ohnehin schon überlastet sind.

Wenn Sicherheit auf der Plattformebene gehandhabt wird, ist sie keine wiederkehrende Krise mehr, sondern wird Teil des Hintergrunds. Das ermöglicht es Teams, schneller voranzukommen, ohne das Risiko zu erhöhen.

Dafür ist eine Plattform da.

Erfahren Sie mehr

• Entdecken Sie das Sicherheits- und Compliance-Modell von Upsun
  Erfahren Sie, wie Upsun Sicherheit als Teil der Plattform und nicht als Add-on behandelt.
• Lesen Sie den technischen Deep Dive zum Thema Container-Hardening Eine detaillierte Beschreibung, wie Images erstellt
  , aktualisiert und getestet werden, finden Sie im Originalartikel im Dev Center.