Zero CVEs at delivery: Why container security belongs in the supply chain

Back in 2010, I wrote a small web tool to generate random galactic sectors for a tabletop role playing game. It started as a Perl application, but these days it’s a single, static Go binary with all of its assets compiled right into the executable. Thousands of game masters have used it, it runs quietly in the public cloud, and for years I rarely touched it.

Like thousands of community tools across the open source ecosystem, my app seems pretty harmless. But harmless code running on top of an unmaintained container image is an open door. The moment you push an image to a registry and walk away, it silently collects known vulnerabilities as the world moves on. Open source developers need a way to keep containers secure without taking on hours of manual patching every week, and that is why we built Red Hat Hardened Images.

The volume of vulnerabilities published each year has outpaced what human triage can handle. In the last 12 months, the National Vulnerability Database recorded 87,487 common vulnerabilities and exposures. That comes out to roughly 240 new CVEs every single day, an 82 percent surge over the prior year. When you package a simple utility inside a standard Linux distribution image, you import hundreds of packages your code never touches. If any of those auxiliary packages develop a vulnerability, your application becomes a viable attack vector into your host infrastructure.

My tabletop app did not need curl, an interactive package manager, or Bash. Yet all of those components lived inside my original deployment image, sitting stale for months between manual updates. Motivated attackers scan cloud environments continuously, looking for precisely these unmaintained, forgotten entry points.

Red Hat Hardened Images tackles this issue by redesigning how we build and deliver container bases. Instead of bloated runtime environments, our factory produces minimal, distroless images across roughly 100 popular runtimes and services, including Go, Python, Node, Java, Ruby, PostgreSQL, and Nginx. We deliberately cut out nonessential tools. If an image does not require a shell to run your code, it does not contain a shell.

Stripping out unnecessary utilities cuts the attack surface immediately, but the automated supply chain behind the scenes is what keeps the image clean over time. Every one of our hardened images is backed by SLSA Level 3 supply chain controls, signed with cosign, and packaged with a verifiable software bill of materials. While our current official service level objective targets 80 percent of vulnerability fixes delivered within seven days of notification, our pipeline median is sitting at 18 hours.

Applying this to my own project took changing two lines in my Dockerfile. I swapped my legacy builder and base distro lines for the Go builder and static images. That single change dropped my final container size by 84 percent, shrinking it from 218 MB down to 35 MB.

More importantly, I hooked up an automated workflow to pull updated hardened images daily. When our automated build pipeline patches an upstream library and pushes a new image tag, my deployment pulls that tag, rebuilds, and redeploys. I do not have to monitor vulnerability feeds or manually compile security hotfixes. At any given hour, my running application is never more than 24 hours behind a patched vulnerability.

Open source thrives because developers build utilities, share them freely, and let communities run with them. We should not demand that every developer spend their weekends triaging security advisories just to keep a community tool online. If you’re building open source applications, you can pull and test these images today at no cost. There’s no subscription, paywall, or account signup required. Pull from registry.access.redhat.com/hi/ or explore the catalog at images.redhat.com.