KI-Agenten in der Container-Security: Erfahrungen aus der Praxis

Die Herausforderung der modernen Container-Security

In der heutigen Softwareentwicklung, insbesondere bei der Verwaltung von Container-Images in Produktionsumgebungen, stellt die Sicherheitsüberwachung eine enorme Belastung dar. Sobald ein neuer CVE-Bericht (Common Vulnerabilities and Exposures) in der Security-Pipeline eingeht, beginnt ein oft ineffizienter Prozess. Scanner identifizieren Schwachstellen, die sich über den gesamten Stack erstrecken, und erzeugen Tickets, die auf eine manuelle Prüfung durch Entwickler warten. Während dieser Wartezeit bleibt die betroffene Anwendung mit bekannten Sicherheitslücken in Betrieb, obwohl längst Korrekturen verfügbar wären. Das Problem ist struktureller Natur: Die schiere Menge an Sicherheitsmeldungen, etwa im Linux-Kernel oder in den zahlreichen verwendeten Bibliotheken und Runtimes, übersteigt die Kapazitäten menschlicher Reviewer bei weitem. Jedes einzelne Image muss kontinuierlich überwacht, bewertet und bei Bedarf neu erstellt werden. Die klassische Antwort, den CI/CD-Prozess lediglich zu beschleunigen, greift zu kurz. Es bedarf einer grundlegend intelligenteren Architektur, die nicht nur schneller baut, sondern präzise entscheidet, wann und was überhaupt gebaut werden muss, um Sicherheitsprobleme effektiv zu lösen.

Das Hummingbird-Projekt: Strategie und Zielsetzung

Das Projekt Hummingbird ist eine Open-Source-Initiative von Red Hat, die darauf abzielt, das CVE-Problem direkt auf der Ebene der Distribution zu adressieren. Im Zentrum stehen die sogenannten Red Hat Hardened Images. Diese Container-Images zeichnen sich durch eine minimale Angriffsfläche aus, da sie nur das absolut Notwendige enthalten. Komponenten wie Shells, Paketmanager oder Debug-Tools werden konsequent aus den Produktions-Images entfernt, um das Risiko bei einer Kompromittierung zu minimieren. Aktuell umfasst das Portfolio über 65 Images für verschiedene Laufzeitumgebungen wie Java, Python, Node.js, Go, .NET und PHP, die auf mehr als 400 RPM-Paketen basieren. Das Team verfolgt dabei ein ambitioniertes Service-level Objective (SLO): Vom Bekanntwerden eines Fixes bis zur Auslieferung des getesteten Images sollen weniger als 24 Stunden vergehen. Das Ziel sind sogenannte Zero-CVE-Images, die zum Zeitpunkt der Auslieferung keine einzige bekannte Schwachstelle aufweisen. Dies wird durch einen vollautomatisierten Prozess erreicht, bei dem keine Korrektur auf eine manuelle Bearbeitung durch Menschen warten muss.

Architekturprinzipien und die Rolle der KI

Was das Hummingbird-Projekt von herkömmlichen CI/CD-Optimierungen unterscheidet, ist die konsequente Trennung von deterministischer Automatisierung und KI-gestützter Analyse. Das Architekturprinzip folgt dem Credo: so viel deterministische Automatisierung wie möglich, so viel Agentic AI wie nötig. Dabei wird ein Konzept der Responsible AI verfolgt, das auf Verantwortung und Rechenschaftspflicht basiert. KI-Agenten fungieren als aktive Teilnehmer im gesamten Softwareentwicklungsprozess, den das Team als Hummingbird Agentic SDLC bezeichnet. Sie unterstützen bei der Analyse, Implementierung und dem Review, doch die finale Entscheidung und damit die Verantwortung liegen stets beim Menschen. Diese Architektur ist darauf ausgelegt, menschliche Entwickler von Routineaufgaben zu entlasten, während komplexe Urteilsfragen durch KI-Agenten aufbereitet werden. Dieser Ansatz ist unabhängig von der spezifischen Distribution oder der Teamgröße und lässt sich als methodisches Modell für andere Organisationen übertragen, die ihre Supply-Chain-Sicherheit durch Automatisierung signifikant erhöhen möchten.

Der technologische Stack im Detail

Die technische Umsetzung basiert auf einem modernen Tool-Stack. Source Control und CI/CD werden vollständig über GitLab abgewickelt. Für die Build-Prozesse kommt Konflux zum Einsatz, ein auf Tekton und OpenShift basierendes System, das speziell für kritische Supply-Chain-Anforderungen konzipiert wurde. Pipelines-as-Code steuert die Auslösung der Prozesse, während Tests auf der verteilten Infrastruktur von Testing Farm durchgeführt werden. Die fertigen Container-Images werden auf Quay.io gehostet, RPM-Pakete finden sich in Pulp-Repositories. Für die Verwaltung von Abhängigkeiten sorgt das Tool Renovate, das automatisch Merge Requests für neue Paketversionen erstellt. Sobald die CI-Tests erfolgreich durchlaufen wurden, werden diese Änderungen deterministisch gemergt. Die KI-Agenten selbst laufen als Python-Prozesse in isolierten Sandbox-Containern ohne Zugriff auf sensible Secrets. Als KI-Modelle werden derzeit Gemini 3.1 Pro Preview und Claude Sonnet verwendet, wobei die Kosten durch Prompt-Caching um 60 bis 70 Prozent gesenkt werden konnten. Im Juni 2026 beliefen sich die API-Kosten für über 300 Sessions auf weniger als 30 Cent pro Session.

Deterministische Arbeit versus Urteilsarbeit

Ein wesentlicher Kern der Architektur ist die strikte Trennung zwischen zwei Klassen von Arbeit. Die deterministische Arbeit umfasst Aufgaben, die nach fest definierten Regeln ablaufen, wie etwa das Einspielen eines verfügbaren Upstream-Package-Updates oder die Synchronisierung von Lockfiles. Diese Prozesse werden vollständig automatisiert, was in den Repositories des Projekts zu über 1.000 automatischen Commits pro Woche führt, ohne dass ein Mensch eingreifen muss. Im Gegensatz dazu steht die Urteilsarbeit. Hierbei handelt es sich um komplexe Fragestellungen, für die einfache Regelwerke nicht ausreichen. Beispiele hierfür sind die Ursachenanalyse für Build-Fehler auf spezifischen Architekturen wie ARM64, die Korrelation von mehreren fehlgeschlagenen Tests oder die Einschätzung, ob eine API-Änderung einen Breaking Change darstellt oder lediglich ein harmloses Refactoring ist. Für diese Aufgaben werden die KI-Agenten hinzugezogen. Diese klare Trennung verhindert die Extremfälle einer Überautomatisierung, bei der Agenten fehlerhafte Entscheidungen treffen könnten, oder einer Unterautomatisierung, die Entwickler mit unnötigen Routineaufgaben belastet.

Die Arbeitsweise der KI-Agenten

Die Steuerung der KI-Agenten erfolgt nicht über hart codierte Logik im Python-Skript, sondern über eine deklarative Konfiguration in Markdown-Dateien. Diese Dateien beschreiben im Klartext, wie ein Agent bei bestimmten Ereignissen vorgehen soll. So gibt es beispielsweise Workflows für die Analyse von Pipeline-Fehlern oder für das Code-Review von Merge Requests. Die Agenten greifen dabei auf verschiedene Datenquellen zu, darunter GitLab-Logs, MR-Diffs, Tekton-Pipeline-Ergebnisse und Testberichte von Testing Farm. Ein Beispiel für eine solche Konfiguration ist der Workflow zur Analyse von Fehlern, der bei jedem Pipeline-Abbruch ausgelöst wird und die Ergebnisse als Kommentar im Merge Request hinterlässt. Diese Transparenz ermöglicht es anderen Teams, das AGENTS.md-Muster zu übernehmen. Die Agenten sind so konfiguriert, dass sie innerhalb bestimmter Token-Budgets arbeiten, um die Effizienz zu wahren. Die Trennung der Workflow-Logik von der Implementierung erlaubt es zudem, die verwendeten KI-Modelle über einfache Parameter auszutauschen, ohne den zugrunde liegenden Code anpassen zu müssen.

Einordnung der Ergebnisse aus der Praxis

Den Berichten der Entwickler zufolge hat sich die Einführung von KI-Agenten in der Container-Security als äußerst effektiv erwiesen. Die Automatisierung der Routineaufgaben entlastet das Team massiv, während die KI-Unterstützung bei der Fehlersuche die Zeit bis zur Behebung kritischer Probleme verkürzt. Einzuordnen ist das so: Das Projekt zeigt, dass KI nicht als Ersatz für menschliche Expertise dient, sondern als Werkzeug zur Skalierung von Security-Prozessen. Die Kombination aus deterministischer Logik für Standardprozesse und KI für komplexe Analysen bildet ein robustes System. Ein besonderes Merkmal der Red Hat Hardened Images ist zudem die Verfügbarkeit von FIPS-Varianten, die kryptografische Module enthalten, welche nach FIPS 140-3 validiert sind. Dies ermöglicht den Einsatz in hochregulierten Umgebungen, da die Images die Compliance-Anforderungen von RHEL-Systemen erben. Im Vergleich zu anderen Ansätzen, wie etwa der Wolfi-Distribution von Chainguard, liegt der Fokus bei Hummingbird stärker auf der Integration in ein bestehendes Enterprise-Ökosystem mit entsprechenden Zertifizierungsgarantien.

Offene Fragen und zukünftige Entwicklungen

Obwohl das Hummingbird-Projekt bereits beachtliche Erfolge bei der Automatisierung der Security-Pipeline erzielt hat, bleiben einige Aspekte offen. Der Quelltext geht beispielsweise nicht detailliert auf die langfristige Wartbarkeit der KI-gesteuerten Workflows ein, wenn die Komplexität der zu analysierenden Software weiter zunimmt. Auch die Frage, wie sich die Agenten bei völlig neuartigen, bisher nicht dokumentierten Angriffsvektoren verhalten, wird nicht explizit beantwortet. Zudem ist die Übertragbarkeit auf proprietäre oder stark abweichende CI/CD-Umgebungen, die nicht auf dem GitLab- und Tekton-Stack basieren, eine Herausforderung, die Anwender individuell lösen müssen. Zukünftige Schritte umfassen die kontinuierliche Verfeinerung der Agenten-Prompts und die mögliche Einbindung weiterer KI-Modelle, um die Kosten und die Präzision weiter zu optimieren. Interessierte Entwickler und Architekten können sich auf der CLC-Konferenz, die vom 11. bis 12. November 2026 in Mannheim stattfindet, weiter über diese Themen der Agentic AI und der digitalen Souveränität informieren.