Container-Images sind für viele Web-Anwendungen längst das Standard-Auslieferungsformat: Ein Image bündelt Applikation, Laufzeitumgebung und Systembibliotheken zu einem festen Paket, das auf jedem Host gleich startet. Genau diese Bündelung erzeugt aber laufenden Pflegeaufwand, denn jede mitgelieferte Bibliothek kann irgendwann eine gemeldete Sicherheitslücke enthalten.

Ein Bericht aus der Praxis beschreibt nun, wie Red Hat mit dem Projekt Hummingbird KI-Agenten für diese Arbeit einsetzt. Erklärtes Zielbild sind Images ohne bekannte Schwachstellen, sogenannte Zero-CVE-Images. Ebenso deutlich wird in den geschilderten Erfahrungen, dass Menschen im Prozess unverzichtbar bleiben.

Warum Image-Pflege so viel Aufwand kostet

CVE steht für Common Vulnerabilities and Exposures – ein öffentliches Verzeichnis, in dem bekannte Sicherheitslücken mit einer eindeutigen Kennung geführt werden. Scanner prüfen ein Container-Image gegen dieses Verzeichnis und melden jede Komponente, für die ein Eintrag existiert.

Der Aufwand entsteht weniger beim Scannen als bei allem danach. Typischerweise fallen an:

  • Bewertung, ob eine gemeldete Lücke im konkreten Einsatzszenario überhaupt erreichbar ist
  • Suche nach einer gepatchten Version der betroffenen Bibliothek
  • Neubau des Images samt Abhängigkeitsauflösung
  • Regressionstests, damit das Update die Anwendung nicht bricht
  • Dokumentation gegenüber Audit, Kundschaft oder interner Compliance

Bei einer Handvoll Images ist das machbar. Bei mehreren Dutzend Images über verschiedene Projekte hinweg wird daraus eine Daueraufgabe, die selten priorisiert wird – bis ein Kunde eine Freigabeliste verlangt oder eine kritische Lücke publik wird.

Was Agentic AI in diesem Kontext bedeutet

Von Agentic AI spricht man, wenn ein KI-System nicht nur einzelne Antworten liefert, sondern eine mehrstufige Aufgabe selbstständig plant, Werkzeuge aufruft und das Ergebnis überprüft. Statt eines Chatverlaufs steht eine Kette von Arbeitsschritten im Mittelpunkt: Zustand erfassen, Änderung vorschlagen, Änderung ausführen, Ergebnis validieren.

Auf Container-Security übertragen passt dieses Muster gut, weil die einzelnen Schritte klar definiert und maschinell prüfbar sind. Ob ein Image nach einem Rebuild noch Treffer im Scanner erzeugt, ist keine Ermessensfrage, sondern ein eindeutiges Ergebnis. Ob die Anwendung danach noch startet, zeigt die Testpipeline. Ein Agent bekommt also unmittelbares, objektives Feedback zu seiner eigenen Arbeit – eine Voraussetzung, die in vielen anderen Automatisierungsszenarien fehlt.

Zero CVE ist ein Zielbild, kein Zustand

Der Begriff Zero-CVE-Image klingt nach Endzustand, beschreibt aber eine Momentaufnahme. Ein Image ohne bekannte Schwachstellen ist genau so lange frei von Treffern, bis die nächste Lücke in einer enthaltenen Komponente veröffentlicht wird. Der Wert liegt deshalb nicht im Etikett, sondern in der Fähigkeit, den Zustand kurzfristig wiederherzustellen.

Damit verschiebt sich die eigentliche Kennzahl: Interessant ist weniger, wie viele Findings ein Image heute hat, sondern wie lange es dauert, bis ein gepatchtes Image gebaut, getestet und ausgerollt ist. Automatisierung zahlt genau auf diese Durchlaufzeit ein.

Wo Menschen im Prozess bleiben

Die geschilderten Praxiserfahrungen betonen, dass die menschliche Rolle nicht entfällt. Das deckt sich mit der Natur der Aufgabe: Ein Scanner-Treffer ist eine Behauptung über ein Risiko, keine Entscheidung. Ob eine Lücke im eigenen Betriebskontext relevant ist, ob ein Versionssprung fachliche Nebenwirkungen hat, ob ein Notfall-Rollout gerechtfertigt ist – das sind Abwägungen mit Kontextwissen, das außerhalb des Images liegt.

Sinnvoll ist deshalb eine Arbeitsteilung: Der Agent übernimmt die reproduzierbaren, mühsamen Anteile – Abhängigkeiten aktualisieren, Images neu bauen, Ergebnisse gegenprüfen, Änderungen als nachvollziehbaren Vorschlag aufbereiten. Die Freigabe und die Risikobewertung bleiben bei Menschen, die das Produkt und dessen Betriebsumgebung kennen.

Voraussetzungen im eigenen Betrieb

Wer solche Automatisierung erwägt, sollte zuerst die Grundlagen prüfen. Ein Agent kann nur automatisieren, was ohnehin skriptbar wäre:

  1. Reproduzierbare Builds: Images müssen sich aus einer versionierten Definition automatisch neu bauen lassen, nicht durch manuelle Schritte.
  2. Aussagekräftige Tests: Ohne automatisierte Prüfungen fehlt dem Agenten das Signal, ob ein Update die Anwendung beschädigt.
  3. Inventar: Es muss bekannt sein, welche Images im Einsatz sind, wo sie laufen und wer sie verantwortet.
  4. Kontrollierte Ausrollwege: Ein automatisch gebautes Image nützt wenig, wenn der Weg in die Produktion manuell und selten begangen wird.
  5. Nachvollziehbarkeit: Jede maschinell erzeugte Änderung braucht dieselbe Prüfspur wie eine menschliche – über Versionskontrolle und Review.

Fehlen diese Bausteine, ist der erste Schritt nicht der KI-Agent, sondern die Pipeline darunter. Andernfalls automatisiert man einen Prozess, der auch von Hand nicht zuverlässig funktioniert.

Einordnung für Web- und Softwareprojekte

Für containerisierte Web-Anwendungen bedeutet die Entwicklung vor allem eines: Sicherheitspflege wandert stärker in die Build-Pipeline und weg von unregelmäßigen manuellen Wartungsfenstern. Wer Builds bereits reproduzierbar und getestet hat, kann agentische Automatisierung schrittweise ergänzen und die Zeit bis zum gepatchten Deployment deutlich verkürzen. Wer diese Basis noch nicht hat, sollte sie zuerst schaffen – sie zahlt sich unabhängig von jedem KI-Werkzeug aus.

Quellen