Für alle, die Container-Images in Produktion betreiben, ist es eine gewohnte Prozedur: Ein neuer CVE-Bericht landet in der Security-Pipeline, Scanner melden Befunde quer durch den Stack, irgendwo wartet ein Ticket auf eine Entwicklerin oder einen Entwickler, die oder der prüft, ob das Image neu gebaut werden muss. In der Zwischenzeit läuft die betroffene Anwendung mit einer bekannten Schwachstelle weiter, für die es längst einen Fix gibt.
Ein strukturelles Problem, kein Team-Versagen
Hier versagt kein einzelnes Team, sondern es offenbart sich ein strukturelles Problem: Es gibt so viele gemeldete CVEs, dass menschliche Reviewer sie nicht mehr bewältigen können. Schon allein im Linux-Kernel kommen Hunderte Sicherheitsmeldungen im Jahr zusammen, hinzu kommen Bibliotheken, Runtimes und Systempakete. Jedes davon muss überwacht, bewertet und bei Bedarf neu gebaut werden, und zwar in jedem Image, das es enthält.
Die klassische Antwort auf das CVE-Problem lautet: mehr Automatisierung im CI/CD-Prozess. Das ist richtig, reicht aber nicht. Automatisierung beschleunigt das Bauen, sie beantwortet noch nicht die Frage, wann gebaut werden soll, was gebaut werden soll und ob der Rebuild das Sicherheitsproblem tatsächlich löst. Es braucht keine schnelleren Pipelines, sondern intelligentere.
Minimale Angriffsfläche, maximale Automatisierung
Red Hats Project Hummingbird ist ein Open-Source-Projekt, das dieses Problem auf der Distributionsseite angeht. Es baut und wartet minimale, gehärtete Container-Images, die Red Hat Hardened Images, unter einem vollautomatischen Supply-Chain-Prozess. Minimal bedeutet dabei: Ein Image enthält nur das Nötigste, Shell, Paketmanager oder Debug-Tools landen nicht im Produktions-Image. Jede Zeile Code, die nicht im Image steckt, reduziert dessen Angriffsfläche.
Das Portfolio umfasst derzeit über 65 Images für Laufzeitumgebungen wie Java, Python, Node.js, Go, .NET und PHP, aufgebaut auf über 400 kontinuierlich überwachten RPM-Paketen. Das Ziel ist ein Sicherheits-Service-Level-Objective, bei dem von der Bereitstellung eines Fixes bis zum fertig getesteten, ausgelieferten Image weniger als 24 Stunden vergehen, angestrebt werden Zero-CVE-Images, also Images ohne eine einzige bekannte Schwachstelle zum Auslieferungszeitpunkt. Jedes Image ist zudem in einer FIPS-Variante verfügbar, die validierte kryptografische Module aus Red Hat Enterprise Linux enthält und damit RHELs Compliance-Posture erbt, relevant vor allem für regulierte Umgebungen. Der Ansatz ist nicht einzigartig, Chainguard verfolgt mit seiner Wolfi-Distribution eine ähnliche Philosophie, allerdings aus dem Alpine-Linux-Ökosystem und ohne RHEL-Kompatibilitätsgarantien.
Deterministische Automatisierung, so viel KI wie nötig
Was das Projekt von einem bloß beschleunigten CI/CD-Prozess unterscheidet, ist das Architekturprinzip: so viel deterministische Automatisierung wie möglich, so viel Agentic AI wie nötig. Dahinter steht ein Verständnis von KI als Responsible AI, bei dem die KI Analysen liefert, Code vorschlägt und Entscheidungen vorbereitet, verantwortlich für das Ergebnis bleibt aber immer ein Mensch. Nur wenn ein Mensch eine Entscheidung trifft, lässt er sich dafür zur Rechenschaft ziehen.
Technisch laufen Source Control und CI/CD vollständig auf GitLab, die zentralen Repositories werden über das Build-System Konflux gebaut und getestet, Tests laufen auf einer verteilten Testinfrastruktur, Container-Images landen auf Quay.io und RPM-Pakete in Pulp-Repositories. Dependency-Updates übernimmt das Tool Renovate rein regelbasiert, ohne KI: Es öffnet automatisch Merge Requests für neue Paketversionen, sobald die CI grün ist, mergen sie selbstständig. Die KI-Agenten selbst laufen als isolierte Sandbox-Prozesse ohne Zugriff auf Secrets oder Deployment-Token, als Modelle kommen je nach Workflow aktuell Gemini 3.1 Pro Preview und Claude Sonnet zum Einsatz. Die Kosten dafür sind überschaubar: Im Juni 2026 lagen die API-Kosten über alle drei produktiven Repositories bei rund 90 US-Dollar für 314 Agent-Sessions, unter 30 Cent pro Session im Schnitt, unter anderem dank Prompt-Caching, das die Kosten um 60 bis 70 Prozent senkt.
Die Workflow-Logik selbst steckt bewusst nicht im Python-Code, sondern in Markdown-Dateien, aus denen jeder Agent seine Arbeitsanweisung liest. Sie beschreiben im Klartext, welche Daten ein Agent zuerst abruft, wie er Fehler klassifiziert und in welcher Reihenfolge er Review-Prioritäten abarbeitet, öffentlich einsehbar im Hummingbird-Repository.
Zwei Klassen von Arbeit
Der entscheidende Entwurfsentscheid ist eine strikte Trennung zwischen zwei Klassen von Arbeit. Deterministische Arbeit ist alles, was sich nach definierten Regeln entscheiden lässt, etwa ein verfügbares Upstream-Package-Update, eine nötige Lockfile-Synchronisierung oder ein CVE-Fix, der bereits im zugehörigen RPM vorliegt. Solche Änderungen werden automatisch als Merge Request erstellt und mergen selbstständig, sobald die CI-Tests grün sind, ohne Ticket, manuelles Review oder Warteschleife. Über 1.000 automatische Commits pro Woche entstehen so.
Urteilsarbeit ist dagegen alles, wofür Regelwerke allein nicht ausreichen: Warum schlägt ein Build auf ARM64 fehl, aber nicht auf x86? Welche der zehn fehlgeschlagenen Tests hängen miteinander zusammen? Ist eine API-Änderung ein Breaking Change, der ein menschliches Review braucht, oder harmloses Refactoring? Hier sind Agenten gefragt. Erfolgt die Trennung zwischen beiden Klassen nicht gezielt, drohen zwei Extreme: Bei zu hohem Automatisierungsgrad treffen Agenten für zu viele Aufgaben plausibel klingende, aber falsche Entscheidungen. Bei zu geringer Automatisierung müssen sich Entwicklerinnen und Entwickler weiter mit Routinearbeiten befassen, für die kein menschliches Urteil nötig wäre.