Well, that escalated quickly: Zero CVEs, lots of vendors

Well, that escalated quickly.

A few years ago, secure container images were a niche concern. The space felt like the men’s room at a Taylor Swift concert: empty… aside from one superfan (me). Today, it’s halftime at an NBA Finals game. There’s a line outside the door, every stall is full, and suddenly, a lot of people are claiming they’ve always cared deeply about bathroom hygiene.

Sorry for the toilet humor. If this already makes you uncomfortable, you should probably stop reading because in the last year, this industry has mostly been panic-cleaning a mess it helped create.

I’m Dan, CEO of Chainguard. We’ve been building containers the hard way for four years, and selling them for over two. That was back when this wasn’t a category and “secure-by-default” wasn’t a phrase people put on slides. Now the space is flooded with “zero-CVE” promises and “hardened” solutions.

This post is about why that happened, why talking about “hardened containers” is the wrong conversation, and what actually needs to change if we don’t want to repeat the same mistakes at a much larger scale.

The container security problem isn’t about hardening images. It’s about trusting where software comes from.

WTF is a “hardened container,” anyway?

Let’s take a step back and talk about what we mean by “hardened container.” It usually means a container image that meets some set of security or compliance criteria: a minimized attack surface (no shell, no package manager, no extra junk), all known vulnerabilities patched, and configuration aligned with standards like CIS, STIG, or FIPS.

That’s all good stuff. If you need this for compliance or regulatory reasons, you really need it. Hardened containers matter, and they’re genuinely hard to do well.

So why aren’t all containers just like this? Because they never were.

Containers succeeded because they made developers faster, not because they made systems safer. Docker took off by prioritizing flexibility, and the early defaults were basically the opposite of what you’d want from a security perspective. The default user is root. Shells are everywhere. Package managers are everywhere. The Docker Hub “Official Images” have been a security nightmare for pretty much their entire existence.

Much of today’s container ecosystem is built from opaque binaries, ad-hoc build pipelines, and Dockerfiles that were never designed to be reproducible or auditable. You can remove all known vulnerabilities and still have no real confidence in how that software was built or what it depends on. Two images can look identical from a CVE standpoint and carry very different levels of risk.

So instead of secure-by-default, the industry ended up with “we’ll fix it later.” Security became something you handled after the fact by scanning and patching whatever showed up in production.

That’s how post-hoc hardening became the norm.

It treats the symptom, not the disease. It’s also like asking NBA Finals ticketholders to bring their own plumber to the game because the pipes are backed up. The process is deeply toilsome: patching, stripping binaries, rebuilding images, changing configs, running policy engines… repeating forever.

You can remove all known vulnerabilities and still have no real confidence in how that software was built or what it depends on. Two images can look identical from a CVE standpoint and carry very different levels of risk.

How we got here

Dockerfiles are at least half the problem here. They give developers a way to do whatever the fuck they want, using an extremely simple syntax. And developers love being able to do whatever the fuck they want, so they did a lot of it.

The trusted supply chains people relied on before (Linux distros) couldn’t keep up with the explosion of weird, bespoke images developers wanted. So curl | bash started spreading everywhere, while apt-get and apk add quietly fell behind.

My co-founder Matt and I tried to solve this at Google with the Distroless project, and we learned something important: you can’t build something that’s both secure and works for developers without controlling the distro itself.

Our different approach

When we started Chainguard, we didn’t want to solve this lazily by slapping a band-aid on it. We asked a different question: what if containers were just… already secure? Already hardened? And still easy to use?

To do that, we knew we’d have to build a full distro.

So that’s what we did. We built and maintained the toolchains. We packaged every version of the open source software we wanted. We built an OS and the automation required to securely build everything—and then we started producing container images on top of it.

Those images happened to be pre-hardened, because there was huge demand for it. But that was a consequence, not the goal.

The false promise of a “hardened containers” market

The explosion of hardened container offerings has helped force a long-overdue conversation. More organizations now recognize that the status quo for consuming open source software isn’t sustainable, and that’s a good thing.

But the market has fixated on zero CVEs and hardened images because it’s easier than fixing the software supply chain.

Broadly speaking, there are two approaches today: 1) post-hoc hardening, and 2) from-source builds.

To fully solve the problem, we do from-source builds, with some configurations producing hardened containers. Others like Wiz, Echo, and Minimus do this too.

Docker has a… weird approach, where they copy filesystem subtrees out of random other images and hope it works. RapidFort and DockerSlim are fully post-hoc.

I don’t believe it’s possible to provide hardened containers with real software choice without from-source builds and your own distro. People call that “lock-in,” but there’s no other honest way to do it. And besides, you’re already locked in if you’re using hardened images built from opaque binaries, abandoned images, and ad-hoc pipelines no one can reproduce.

Even the name “hardened containers” is backwards. It implies you’re taking something sketchy and trying to fix it after the fact.

Every time I hear that framing — hardening containers built from random curl | bash scripts and binaries compiled by strangers on the internet — it reminds me of those “hardening” pills you see in gas station bathrooms. Do they work? Maybe. But you might also go blind.

Here’s a simple rule of thumb when reading vendor websites: if you hear “existing distro compatibility,” read that as “we don’t know where your binaries come from, and you shouldn’t either.” If you hear “post-hoc hardening,” that’s someone trying to sell you gas station pills.

So, what should we be talking about?

Open source is moving too fast, and at too much scale, for unmanaged supply chains to keep working. At some point, you either know where your software comes from — how it was built, what went into it, and how it gets updated — or you don’t ship it at all.

Hardened containers help at the margins. Trusted supply chains are what actually scale.

If hardened containers disappeared tomorrow, Chainguard would still exist. What organizations really need is a trusted, managed supply chain for all of their open source. That’s why we introduced trusted Libraries last year, which is another step toward fixing your supply chain.

What we’re actually building is a next-generation operating system for open source software: a distro that moves at the speed of open source, with the benefits of a managed, secure supply chain. Think the guarantees of a Linux distro, with the breadth of PyPI, Maven Central, npm, and everything else developers rely on.

And yes, that means making things more secure—but it also means making developers’ lives better, not just more constrained.

Here’s what I think the next year looks like, and what it’ll take to win:

• Containers become truly ubiquitous, at massive scale

• Real “agent in the loop” workflows for building, patching, updating, and — most importantly — testing

• First-party content: actively improving the open source software itself

• Expanding beyond containers into libraries, laptop binaries, and everything else developers run

• Migration costs approaching zero, which makes “lock-in” mostly irrelevant

The current rush to harden images is understandable, but it’s focused on what’s easiest to clean, not what’s actually broken. The hardened containers market is a symptom. The real problem (and the real opportunity) is whether we finally fix the systems underneath the artifacts we ship.

We’re betting on the plumbing.