Проект Hummingbird от Red Hat автоматизирует устранение уязвимостей в контейнерах с помощью агентов ИИ

KI-Agenten in der Container-Security: Erfahrungen aus der Praxis Zero-CVE-Images durch Agentic AI: Red Hats Hummingbird-Projekt zeigt, wie KI-Agenten Container-Security automatisieren – und wo Menschen unverzichtbar bleiben. - Valentin Rothberg - Michael Krausch-Hofmann 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 dann ein Ticket auf einen Entwickler, 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. 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. Mehr zu Agentic AI, digitaler Souveränität und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim. Jetzt Tickets zum Frühbucherpreis sichern. Das Problem, das kein Patch-Zyklus löst 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. Wir benötigen keine schnelleren Pipelines. Wir benötigen intelligentere. Dieser Artikel ist ein Erfahrungsbericht darüber, wie wir das in Project Hummingbird angegangen sind. Die Methodik dahinter, also die Trennung zwischen Regel und Urteil, die Nutzung von Dokumentation als Agentenkontext und der strukturierte Feedback-Loop, ist unabhängig von Distribution, Tooling oder Teamgröße übertragbar. Red Hat Hardened Images: Minimale Angriffsfläche, maximale Automatisierung Project Hummingbird ist ein Open-Source-Projekt, mit dem Red Hat das CVE-Problem auf der Distributionsseite angehen will. Das Projekt 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 ist, reduziert dessen Angriffsfläche. Wer einen Container kompromittieren will, muss mit dem arbeiten, was darin enthalten ist. Derzeit umfasst das Portfolio über 65 Images für Laufzeitumgebungen wie Java, Python, Node.js, Go, .NET und PHP, aufgebaut auf über 400 RPM-Paketen (Red Hat Package Manager), die wir kontinuierlich überwachen. Dabei folgen wir dem selbst gesteckten Ziel der Sicherheits-SLO (Service-level Objective): Von der Bereitstellung eines Fixes bis zum fertig getesteten, ausgelieferten Image vergehen weniger als 24 Stunden. Das erklärte Ziel sind Zero-CVE-Images, also Images ohne eine einzige bekannte Schwachstelle zum Auslieferungszeitpunkt. Wir erreichen das täglich, weil kein Fix auf einen Menschen wartet, der ihn bemerkt. Die Red Hat Hardened Images sind unter images.redhat.com verfügbar. Wer sich selbst ein Bild machen will, findet dort die vollständige Übersicht. Jedes Image ist in einer FIPS-Variante verfügbar, die FIPS 140-3 validierte kryptografische Module aus Red Hat Enterprise Linux (RHEL) enthält. Die Validierung greift, wenn der Container auf einem RHEL-System im FIPS-Modus läuft. Damit erben die Images RHELs Compliance-Posture (FIPS-, STIG- und CIS-Benchmarks), was insbesondere für regulierte Umgebungen relevant ist und einen entscheidenden Unterschied gegenüber Alternativen ohne RHEL-Basis ausmacht. Der Ansatz ist nicht einzigartig. Chainguard verfolgt mit seiner Wolfi-Distribution eine ähnliche Philosophie: minimale Angriffsfläche, kontinuierliche Updates, SBOM-Transparenz (Software Bill of Materials). Der wesentliche Unterschied liegt im Ökosystem: Wolfi kommt aus der Alpine-Linux-Welt, ist musl/apk-basiert. RHEL-Kompatibilitätsgarantien und -Zertifizierungen spielen dort keine Rolle. Der Hummingbird-Ansatz ist auch auf andere Paketsysteme übertragbar, deshalb beschreibt dieser Artikel weniger das „Was“ als das „Wie“ auf dem Weg zu einer CVE-freien Pipeline. Die Pipeline: Automatisierung als Architekturprinzip Was Hummingbird von einem „besseren CI/CD-Prozess“ unterscheidet, ist das Architekturprinzip. Die Pipeline ist keine beschleunigte Version des alten Workflows, sondern grundlegend anders. Unser Credo lautet: so viel deterministische Automatisierung wie möglich, so viel Agentic AI wie nötig. Dahinter steckt ein Verständnis von KI, das wir als Responsible AI bezeichnen: Verantwortung und Rechenschaftspflicht. KI kann Analysen liefern, Code vorschlagen, Entscheidungen vorbereiten. Verantwortlich für das Ergebnis ist letztlich immer ein Mensch. Nur wenn ein Mensch eine Entscheidung trifft, kann man ihn dafür zur Rechenschaft ziehen. Das Ergebnis ist der Hummingbird Agentic SDLC, ein Softwareentwicklungsprozess, in dem KI-Agenten als aktive Teilnehmer in jede Phase eingebunden sind: von der Anfrage über Analyse, Implementierung und Review bis zum Merge. Videos by heise Der Stack im Detail Source Control und CI/CD laufen vollständig auf GitLab. Die drei zentralen Repositories (redhat/hummingbird/containers, rpms, tools) werden über Konflux gebaut und getestet, einem auf Tekton und OpenShift basierenden Build-System, das Red Hat intern und für kritische Supply-Chain-Anforderungen einsetzt. Pipelines-as-Code (PAC) steuert, welche Pipelines bei welchen Ereignissen ausgelöst werden. Tests laufen auf Testing Farm, einer verteilten Testinfrastruktur. Container-Images landen auf Quay.io und RPM-Pakete in Pulp-Repositories. Pulp ist ein Open-Source-Repository-Manager für Pakete in vielen verschiedenen Formaten, darunter RPM, und für Container. Dependency-Updates übernimmt Renovate: Das Tool öffnet automatisch Merge Requests für neue Paketversionen. Sobald die CI grün ist, mergen sie selbstständig. Hier gibt es keine Heuristik und keine KI, sondern nur deterministische Regeln. Die Agenten laufen als Python-Prozesse in isolierten Sandbox-Containern (quay.io/hummingbird-ci/gitlab-ci) ohne Zugriff auf Secrets oder Deployment-Token. Das lokale Container-Management übernimmt Podman, in der Produktion ist es OpenShift. Als KI-Modelle kommen aktuell Gemini 3.1 Pro Preview und Claude Sonnet zum Einsatz, je nach Workflow und Repository, andere Modelle sind über Konfigurationsparameter jederzeit möglich. Die Kosten sind in diesem Setup überschaubar: Über alle drei produktiven Repositories hinweg lagen die API-Kosten im Juni 2026 bei rund 90 US-Dollar für 314 Agent-Sessions, also unter 30 Cent pro Session im Schnitt. Prompt-Caching, das bereits gesehene Kontextanteile nicht neu berechnet, reduziert die Kosten dabei um 60 bis 70 Prozent. Die Workflow-Logik ist bewusst außerhalb des Python-Codes gehalten: Jeder Agent liest seine Arbeitsanweisung aus einer Markdown-Datei. Ein gekürzter Ausschnitt aus der Konfiguration zeigt, wie das zusammenspielt: # AGENTS.md-Muster mdworkflows: analyze-failures: trigger: pipeline # wird bei jedem Pipeline-Fehler ausgelöst prompt: workflows/analyze-failures.md action: post_gitlab_note # Befund als MR-Kommentar model: gemini-3.1-pro-preview data_sources: gitlab: {} # CI-Logs, MR-Diff konflux: {} # Tekton PipelineRuns und TaskRuns testing_farm: {} # Testergebnisse code-review: trigger: merge_request prompt: workflows/code-review.md model: gemini-3.1-pro-preview max_iterations: 15 context_limit: 500000 # Token-Budget für große Diffs Die Workflow-Markdown-Dateien sind öffentlich im Hummingbird-Repository einsehbar und beschreiben im Klartext, wie der Agent vorgeht: Welche Daten er zuerst abruft, wie er Fehler klassifiziert, in welcher Reihenfolge er Review-Prioritäten abarbeitet. Wer das AGENTS.md-Muster übernehmen will, findet dort konkrete Vorbilder. Zwei Klassen von Arbeit Der entscheidende Entwurfsentscheid sieht eine strikte Trennung zwischen zwei Klassen von Arbeit vor: Deterministische Arbeit ist alles, was sich nach definierten Regeln entscheiden lässt: Ein Upstream-Package-Update ist verfügbar. Eine Lockfile-Synchronisierung ist nötig. Ein CVE-Fix liegt im zugehörigen RPM vor. Solche Änderungen werden automatisch als Merge Request erstellt. Sobald die CI-Tests grün sind, mergen sie selbstständig, ohne Ticket, manuelles Review oder Warteschleife. Über 1.000 automatische Commits pro Woche entstehen auf diese Weise in unseren Repositories. Urteilsarbeit ist alles, wofür Regelwerke allein nicht ausreichen: Warum schlägt dieser Build auf ARM64 fehl, aber nicht auf x86? Welche der zehn fehlgeschlagenen Tests hängen miteinander zusammen? Ist diese API-Änderung ein Breaking Change, der ein menschliches Review benötigt, oder ein harmloses Refactoring? Zur Klärung sind Agenten gefragt. Diese Trennung macht den Kern der Architektur aus. Erfolgt die Trennung aber nicht gezielt, drohen zwei Extremfälle: Ist der Grad der Automatisierung zu hoch, dann sind Agenten für zu viele Aufgaben verantwortlich und treffen im Zweifelsfall zwar plausibel klingende, aber dennoch falsche Entscheidungen. Ist zu wenig automatisiert, müssen sich Entwicklerinnen und Entwickler mit Routinearbeiten beschäftigen, für die kein menschliches Urteil erforderlich wäre.