1,000 Merge Requests a Week and Nobody Clicked Approve
Container images ship with hundreds of packages you didn't choose, each one a potential vulnerability. When AI-assisted security research began surfacing real CVEs at an unprecedented rate, we had to rethink how our supply chain worked from the ground up.
This talk is the story of building a fully autonomous container supply chain that monitors upstream releases, detects vulnerabilities before CVEs are published, generates package updates, builds across architectures, runs tests, and ships patched images — processing roughly 1,000 merge requests per week without a human clicking approve. I'll share the architecture decisions that worked, the ones that didn't, and the surprising non-technical problems we had to solve along the way.
You'll leave with practical patterns you can apply to your own pipelines: RPM lockfiles for deterministic builds, reproducible builds that let anyone verify your output, policy-driven automation boundaries that separate "the machine handles this" from "a human needs to look," and the guardrails that make autonomous merging safe rather than reckless.
The CVE landscape is changing fast. AI-assisted vulnerability discovery is pushing annual CVE counts past 60,000 and accelerating. Firefox fixed 423 security bugs in April 2026 alone — more than the previous 15 months combined.
Traditional approaches to container patching — wait for a scanner report, open a ticket, assign someone, review, merge, release — cannot keep up with this volume.
Project Hummingbird is Red Hat's answer to this problem: minimal, distroless container images with a fully autonomous supply chain. As the Builds and Releases workstream lead, I've spent the past year building the pipeline that makes near-zero CVE images possible at scale. This talk is not a product pitch — it's the engineering story behind the automation, told through the failures and surprises we encountered.
I'll cover four main areas:
1. Why autonomous? The math that convinced us humans-in-the-loop wouldn't scale. How we quantified the gap between CVE discovery rate and our team's patch throughput, and why "hire more people" wasn't a viable answer.
2. The architecture. Hermetic builds with pinned RPM lockfiles (think Cargo.lock for containers). Two parallel upstream monitoring systems — dist-git sync and direct release watching — that create auto-merge merge requests. A dual-pipeline design where RPM builds feed container builds, each with their own test and validation gates.
3. What went wrong. Reproducible builds sound simple until you discover RPM database journal modes, non-deterministic package installation ordering, OCI annotation sorting, and a dozen other sources of non-determinism that took months to solve. Policy boundaries that were too loose and too tight before we found the right line. The day we learned why you need a modification_status field on every package.
4. Patterns you can steal. Lockfile-based dependency pinning for containers. Policy-driven auto-merge with explicit "clean" vs. "modified" classification. Reproducible build verification in CI (rebuild and compare on every merge request). SBOM generation as a build artifact, not an afterthought.
This talk is for anyone running containers in production who's tired of triaging base image CVEs. You don't need to adopt our exact toolchain — the patterns are portable to any CI/CD system. First-time attendees and experienced practitioners will both find actionable takeaways.
Scott Hebert is a Senior Principal Software Engineer at Red Hat with over 15 years of experience in cloud-native infrastructure, container security, and DevSecOps. He served as an architect on Konflux, Red Hat's open source software supply chain security platform, and currently works on Red Hat Hardened Images and Project Hummingbird — a next-generation initiative to deliver ultra-minimalist, distroless container images that dramatically reduce CVE exposure in production environments.
Scott is passionate about making supply chain security practical and accessible for development teams, and brings a builder's perspective to the intersection of AI infrastructure and software integrity.