Warum die Containersicherheit für Entwickler eine Herausforderung bleibt

Eine BellSoft-Umfrage zeigt, dass Sicherheitsvorfälle in Containern aufgrund reaktiver Praktiken und ihrer Komplexität häufig vorkommen.

Written By
Ken Underhill
Ken Underhill
Jan 30, 2026
5 minute read
eSecurity Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

Sicherheitsvorfälle in Containern sind für Entwicklungsteams zunehmend eher die Regel als eine seltene Ausnahme. 

Eine neue BellSoft-Umfrage ergab, dass fast jeder vierte Entwickler bereits einen Sicherheitsvorfall im Zusammenhang mit Containern erlebt hat. Das verdeutlicht eine wachsende Lücke zwischen Sicherheitszielen und den Tools und Praktiken, auf die sich Organisationen verlassen. 

„Die Daten zeigen, dass das Sicherheitsbewusstsein zwar hoch ist, die derzeitigen Ansätze aber nicht nachhaltig sind: 49 % fehlt die Zeit für Wartungsarbeiten, und 40 % aktualisieren reaktiv“, sagte Dmitry Chuyko, Performance Architect bei BellSoft, in einer E-Mail an eSecurityPlanet.

Er fügte hinzu: „Da 48 % vorgehärtete Images als wichtigste Lösung anfordern – mehr als jede andere Verbesserung –, bestätigen die Daten, dass gehärtete Images eine praktische Antwort auf reale betriebliche Herausforderungen sind, und liefern überzeugende Argumente dafür, sie als neuen Standard für Unternehmensplattformen einzuführen.“  

Warum sich Lücken bei der Containersicherheit schnell ausweiten

Container bilden das Herzstück der modernen Anwendungsbereitstellung. Das bedeutet, dass selbst kleine Sicherheitslücken sich schnell über CI/CD-Pipelines, Cloud-Infrastrukturen und Workloads in der Produktion ausweiten können.

Die Umfrage von BellSoft zeigt, dass die meisten Teams zwar die Containersicherheit als Priorität anerkennen, sich viele aber weiterhin auf reaktive Ansätze verlassen, durch die bekannte Schwachstellen deutlich länger als beabsichtigt in der Produktion verbleiben.

Vorfälle in Containern verdeutlichen die Lücke bei der Behebung

Die Auswirkungen dieser Lücke sind bereits sichtbar. Fast jeder vierte Befragte (23 %) gab an, im vergangenen Jahr einen Sicherheitsvorfall im Zusammenhang mit Containern erlebt zu haben. 

Die Herausforderung besteht nicht in einem mangelnden Bewusstsein für Schwachstellen, sondern im Tempo ihrer Behebung. 

Während sich die Zeit zwischen der Veröffentlichung einer Schwachstelle und ihrer Behebung oft über Wochen oder Monate erstreckt, können Angreifer neu veröffentlichte Schwachstellen zunehmend innerhalb von Tagen für Angriffe instrumentalisieren. 

Dieses Ungleichgewicht führt dazu, dass Organisationen mit bekannten Sicherheitslücken arbeiten, die sich nur schwer schnell schließen lassen.

Advertisement

Menschliches Versagen bleibt ein wesentlicher Risikofaktor

Menschliches Versagen erwies sich als wesentlicher Faktor für Sicherheitsprobleme bei Containern; 62 % der Befragten nannten es. 

Diese Fehler sind häufig auf komplexe Tools, begrenzte Zeit und Ressourcen sowie den Druck zurückzuführen, Software schnell bereitzustellen. 

In der Praxis können selbst gut konzipierte Sicherheitskontrollen versagen, wenn Entwicklern die nötige Klarheit, Automatisierung oder Kapazität fehlt, um sie in verschiedenen Umgebungen konsequent anzuwenden.

Betrieblicher Komfort vergrößert die Angriffsfläche

Betrieblicher Komfort verschärft das Problem zusätzlich. Entwickler berichteten von einer weit verbreiteten Nutzung von Shells, Paketmanagern und gängigen Hilfsprogrammen in Basis-Container-Images. 

Diese Tools sind bei der Entwicklung und beim Debugging zwar wertvoll, vergrößern aber in der Produktion die Angriffsfläche. 

Insbesondere Paketmanager erhöhen das Risiko, da sie die Installation zusätzlicher Komponenten zur Laufzeit ermöglichen – viele davon sind unnötig, nicht nachverfolgt und führen im Laufe der Zeit neue Schwachstellen ein.

Aufgeblähte Basis-Images erhöhen das Risiko durch Schwachstellen

Die Auswahl des Basis-Images fügt eine weitere Risikoschicht hinzu. Mehr als die Hälfte der Befragten gab an, in ihren Containern Allzweck-Linux-Distributionen wie Ubuntu, Debian oder auf Red Hat basierende Systeme zu verwenden. 

Diese Images enthalten häufig Hunderte von Paketen, die Anwendungen nie verwenden. Jedes einzelne stellt jedoch eine potenzielle Schwachstelle dar, die überwacht und behoben werden muss. 

Wird eine neue CVE veröffentlicht, müssen Sicherheitsteams die Behebung für eine große Zahl von Container-Instanzen bewerten und koordinieren – unabhängig davon, ob das betroffene Paket relevant ist. Das erhöht den betrieblichen Aufwand und verlangsamt die Reaktionszeiten.

Advertisement

Reaktive Sicherheitskontrollen dominieren Containerumgebungen

Trotz dieser Herausforderungen verlassen sich die meisten befragten Organisationen weiterhin auf grundlegende reaktive Sicherheitskontrollen. 

Vertrauenswürdige Registries und Tools zur Schwachstellensuche waren die am häufigsten eingesetzten Maßnahmen, während proaktivere Ansätze – etwa Software-Stücklisten (SBOMs), das Signieren von Images oder hardwarebasierte Isolation – weiterhin weniger verbreitet sind. 

Bemerkenswerte 10 % der Befragten gaben an, über die standardmäßigen Docker- oder Kubernetes-Tools hinaus keine zusätzlichen Maßnahmen zur Containersicherheit einzusetzen.

Verzögerte Aktualisierungen lassen bekannte Schwachstellen in der Produktionzurück

Die Aktualisierungspraktiken verdeutlichen das Problem zusätzlich. Während einige Teams Container-Images mit jedem Release oder als Reaktion auf kritische Schwachstellen aktualisieren, gab ein Drittel an, dies monatlich, selten oder nur wenige Male pro Jahr zu tun.

In der heutigen Bedrohungslandschaft führen diese Verzögerungen dazu, dass bekannte Schwachstellen noch lange in der Produktion bestehen, nachdem Exploits verfügbar geworden sind.

Diese Herausforderungen werden durch das Spannungsverhältnis zwischen Sicherheit und Leistung noch verstärkt. Obwohl Sicherheit bei der Auswahl von Basis-Images als wichtigste Priorität genannt wird, müssen Teams auch Image-Größe, Laufzeiteffizienz und Kosten berücksichtigen. 

Java-Anwendungen bringen zusätzliche Komplexität mit sich, da die meisten Befragten auf Allzweck-JDKs setzen, die nicht für containerisierte Umgebungen konzipiert wurden und häufig mit bekannten Schwachstellen ausgeliefert werden. 

Die Optimierung dieser Laufzeitumgebungen erfordert spezielles Fachwissen und erhöht den Entwicklungsaufwand sowie die Cloud-Kosten.

Daher sehen sich viele Teams gezwungen, zwischen dem Zeitaufwand für Optimierung und Patchen oder der Akzeptanz höherer Risiken und Ineffizienz abzuwägen – ein Ansatz, der mit zunehmender Größe der Containerumgebungen immer schwerer aufrechtzuerhalten ist.

Advertisement

Wie Organisationen das Risiko durch Containersicherheit senken können

Um das Risiko durch Containersicherheit zu senken, reicht es nicht aus, erst auf Schwachstellen zu reagieren, nachdem sie in der Produktion aufgetreten sind. 

Da sich die Zeiträume für Angriffe weiter verkürzen, benötigen Organisationen einen mehrschichtigen Ansatz, der die Gefährdung von Anfang an minimiert und zugleich die Möglichkeiten zur Erkennung und Reaktion verbessert. 

  • Verwenden Sie vorgehärtete, auf Sicherheit ausgerichtete Basis-Images, um die Gefährdung durch Schwachstellen und den betrieblichen Aufwand zu verringern.
  • Minimieren Sie Tools und Pakete in Produktions-Images und trennen Sie Debug-Builds von Laufzeit-Images.
  • Erhöhen Sie die Häufigkeit der Aktualisierung von Container-Images und automatisieren Sie Neubuilds, wenn sich Basis-Images oder Abhängigkeiten ändern.
  • Verankern Sie Kontrollen für die Sicherheit früher in CI/CD-Pipelines, statt sich ausschließlich auf Scans nach der Bereitstellung zu verlassen.
  • Setzen Sie die Herkunft von Images und Laufzeiteinstellungen nach dem Prinzip der geringsten Rechte durch sowie die Isolation von Workloads, um den Schadensradius zu begrenzen.
  • Verbessern Sie die Laufzeittransparenz, indem Sie das Container-Verhalten auf Anomalien und Konfigurationsabweichungen überwachen.
  • Validieren und testen Sie regelmäßig Pläne zur Reaktion auf Vorfälle, um sicherzustellen, dass Teams Sicherheitsvorfälle im Zusammenhang mit Containern schnell eindämmen und beheben können.

Diese Schritte helfen Organisationen, die Containersicherheit in Build-, Bereitstellungs- und Laufzeitumgebungen zu stärken. 

Containersicherheit im großen Maßstab neu denken

Die Umfrageergebnisse legen nahe, dass die Herausforderungen bei der Containersicherheit weniger durch mangelndes Bewusstsein als durch die Schwierigkeit entstehen, wirksame Praktiken im großen Maßstab aufrechtzuerhalten. 

Da Umgebungen komplexer werden und sich die Zeiträume für Angriffe verkürzen, könnte es für Organisationen, die sich hauptsächlich auf reaktive Kontrollen verlassen, zunehmend schwieriger werden, Schritt zu halten. 

Die Verankerung von Sicherheit in den Grundlagen von Containern durch gehärtete Images, einfachere Tools und Automatisierung kann dazu beitragen, Risiken zu senken und zugleich effiziente, skalierbare Abläufe zu unterstützen.

Diese Herausforderungen veranlassen viele Organisationen dazu, Zero-Trust-Lösungen zu erkunden, die implizites Vertrauen begrenzen und den Zugriff in containerisierten Umgebungen kontinuierlich überprüfen.

Ken Underhill

Ken Underhill is an award-winning cybersecurity professional, bestselling author, and seasoned IT professional. He holds a graduate degree in cybersecurity and information assurance from Western Governors University and brings years of hands-on experience to the field.

eSecurity Planet Logo

eSecurity Planet is a leading resource for IT professionals at large enterprises who are actively researching cybersecurity vendors and latest trends. eSecurity Planet focuses on providing instruction for how to approach common security challenges, as well as informational deep-dives about advanced cybersecurity topics.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.