If you run container images in production, this routine will feel familiar: a new CVE report lands in the security pipeline, scanners flag findings across the stack, and somewhere a ticket sits waiting for a developer to check whether the image needs rebuilding. In the meantime, the affected application keeps running with a known vulnerability that already has a fix available.
A structural problem, not a team failure
No single team is failing here, this reveals a structural problem: there are simply too many reported CVEs for human reviewers to keep up with. The Linux kernel alone racks up hundreds of security advisories a year, on top of libraries, runtimes, and system packages. Every one of them has to be monitored, assessed, and rebuilt if necessary, in every image that includes it.
The classic answer to the CVE problem is more automation in the CI/CD process. That's correct, but not enough. Automation speeds up the building, it doesn't answer the question of when to build, what to build, and whether the rebuild actually fixes the security problem. What's needed isn't faster pipelines, but smarter ones.
Minimal attack surface, maximum automation
Red Hat's Project Hummingbird is an open-source project tackling this problem on the distribution side. It builds and maintains minimal, hardened container images, the Red Hat Hardened Images, under a fully automated supply chain process. Minimal means an image contains only what's strictly needed, no shell, package manager, or debug tools ship in the production image. Every line of code that isn't in the image shrinks its attack surface.
The portfolio currently covers more than 65 images for runtimes like Java, Python, Node.js, Go, .NET, and PHP, built on more than 400 continuously monitored RPM packages. The goal is a security service-level objective under which less than 24 hours pass between a fix becoming available and a fully tested, shipped image, aiming for zero-CVE images, meaning images with not a single known vulnerability at delivery time. Every image is also available in a FIPS variant containing validated cryptographic modules from Red Hat Enterprise Linux, inheriting RHEL's compliance posture, which matters especially for regulated environments. The approach isn't unique, Chainguard pursues a similar philosophy with its Wolfi distribution, though coming from the Alpine Linux ecosystem and without RHEL compatibility guarantees.
Deterministic automation, as much AI as needed
What sets the project apart from a merely faster CI/CD process is its architectural principle: as much deterministic automation as possible, as much agentic AI as necessary. Behind that sits an understanding of AI the team calls responsible AI, where AI delivers analysis, suggests code, and prepares decisions, but a human always remains accountable for the outcome. Only when a human makes the decision can they be held responsible for it.
Technically, source control and CI/CD run entirely on GitLab, the central repositories are built and tested through the Konflux build system, tests run on a distributed test infrastructure, container images land on Quay.io, and RPM packages in Pulp repositories. Dependency updates are handled by the tool Renovate on a purely rule-based basis, no AI involved: it automatically opens merge requests for new package versions, and they merge on their own once CI turns green. The AI agents themselves run as isolated sandbox processes with no access to secrets or deployment tokens; depending on the workflow, current models include Gemini 3.1 Pro Preview and Claude Sonnet. The cost is modest: in June 2026, API costs across all three production repositories came to around 90 US dollars for 314 agent sessions, under 30 cents per session on average, helped by prompt caching, which cuts costs by 60 to 70 percent.
The workflow logic itself deliberately doesn't live in the Python code but in markdown files that each agent reads its instructions from. They describe in plain language which data an agent fetches first, how it classifies errors, and in what order it works through review priorities, publicly viewable in the Hummingbird repository.
Two classes of work
The key design decision is a strict separation between two classes of work. Deterministic work is anything that can be decided by defined rules, such as an available upstream package update, a needed lockfile sync, or a CVE fix already present in the relevant RPM. Such changes get created automatically as merge requests and merge on their own once CI tests pass, no ticket, manual review, or queue involved. Over 1,000 automatic commits a week result from this.
Judgment work, by contrast, is everything rulebooks alone can't resolve: why does a build fail on ARM64 but not on x86? Which of ten failing tests are related? Is an API change a breaking change that needs human review, or harmless refactoring? This is where agents come in. Without a deliberate separation between the two classes, two extremes threaten: too much automation, and agents end up responsible for too many tasks, making decisions that sound plausible but are wrong. Too little automation, and developers keep dealing with routine work that never needed human judgment in the first place.