Container-Sicherheit: Java-Entwickler zwischen Anspruch und Wirklichkeit

Die Diskrepanz zwischen Sicherheitszielen und tatsächlicher Praxis wird immer größer: Eine aktuelle Erhebung des OpenJDK-Anbieters BellSoft offenbart gravierende Lücken in der Container-Absicherung bei Java-Projekten. Fast ein Viertel der befragten Fachkräfte musste bereits Sicherheitsvorfälle bewältigen – doch die eingesetzten Strategien verschärfen das Problem häufig mehr, als sie es lösen.

Umfrageergebnisse zeigen kritische Schwachstellen

BellSoft hat im Oktober auf der Devoxx 2025 insgesamt 427 IT-Fachleute zum Thema Container-Sicherheit befragt. Die Resultate verdeutlichen, dass trotz einer mittlerweile ausgereiften Container-Infrastruktur elementare Sicherheitsfragen nach wie vor ungeklärt bleiben. Die Studie untersucht, wie Entwickler ihre Container-Images zusammenstellen, welche Schutzmaßnahmen sie ergreifen und wo aktuelle Praktiken ihre selbst gesteckten Sicherheitsziele verfehlen.

Jeder vierte Befragte bereits von Incident betroffen

Die Zahlen sprechen eine deutliche Sprache: 23 Prozent der Teilnehmer gaben an, schon mindestens einen Sicherheitsvorfall im Container-Umfeld erlebt zu haben. Das Hauptproblem liegt dabei nicht in der Entdeckung von Schwachstellen, sondern in der Zeitspanne zwischen Bekanntwerden und tatsächlicher Behebung. Während dieser Phase – die sich häufig über Wochen oder gar Monate erstreckt – operieren Organisationen mit dokumentierten Sicherheitsrisiken.

Menschliches Versagen und fehlerhafte Toolauswahl

62 Prozent der Befragten identifizieren menschliches Versagen als Hauptursache für Sicherheitslücken bei Containern. Bei den im Basis-Container genutzten Werkzeugen führen Shells mit 54 Prozent die Liste an, gefolgt von Paketmanagern mit 39 Prozent. Letztere stellen ein besonders kritisches Risiko dar: Sie vergrößern die Angriffsfläche sowohl unmittelbar als auch mittelbar durch die Möglichkeit, zur Laufzeit weitere unnötige Komponenten nachzuinstallieren.

Als praxisnähere Alternative empfiehlt sich der Einsatz gehärteter, minimaler Runtime-Images in Kombination mit umfangreicheren Debug-Varianten für die Entwicklungsphase. Dieser Ansatz ermöglicht sowohl sichere Produktivumgebungen als auch effiziente Diagnose ohne Kompromisse.

Aufgeblähte Distributionen erhöhen Verwundbarkeit

55 Prozent der Studienteilnehmer nutzen umfassende Linux-Distributionen wie Ubuntu, Debian oder Red-Hat-basierte Systeme mit hunderten von Paketen, die von den eigentlichen Anwendungen niemals verwendet werden. Jedes einzelne dieser Pakete repräsentiert eine potenzielle Schwachstelle, die regelmäßige Sicherheitsaktualisierungen erfordert. Tritt eine Verwundbarkeit auf, müssen Sicherheitsteams die Auswirkungen evaluieren und über tausende Instanzen hinweg koordinieren – unabhängig davon, ob die betroffene Anwendung das fragliche Paket überhaupt einsetzt.

Reaktive statt proaktive Sicherheitsstrategien

Die meistgenutzten Sicherheitsmechanismen sind vertrauenswürdige Registries mit 45 Prozent sowie Schwachstellen-Scans mit 43 Prozent. Diese Methoden stellen zwar grundlegende Bausteine der Container-Sicherheit dar, führen jedoch zu einem reaktiven Ansatz: Unternehmen reagieren permanent auf neu entdeckte Schwachstellen, anstatt durch präventive Maßnahmen das Risiko von vornherein zu minimieren.

Beim Update-Verhalten zeigt sich ein gemischtes Bild: 31 Prozent aktualisieren Container-Images mit jeder neuen Version, 26 Prozent bei kritischen Schwachstellen. Allerdings aktualisieren 33 Prozent lediglich monatlich, selten oder nur wenige Male jährlich – ein erhebliches Risiko für Anwendungen und Organisationen.

Gehärtete Images als Lösungsansatz

48 Prozent der Befragten sehen in vorab gehärteten, sicherheitsorientierten Basis-Images das größte Potenzial für verbesserte Container-Sicherheit. Solche vom Anbieter gepflegten Images adressieren die Kernursachen heutiger Herausforderungen direkt und reduzieren Schwachstellen, Betriebsaufwand, Cloud-Kosten sowie das Risiko menschlicher Fehler.