Over the past 12 months, vendors across cloud-native infrastructure have converged on the same conclusion: the market wants image hardening. Docker went GA with Docker Hardened Images last May, then made the whole catalog free and open source in December 2025. In July, Broadcom’s Tanzu division launched Bitnami Secure Images. Chainguard built its Assemble 2026 conference in March around the same theme. Google Cloud Next 2026 put Wiz, now part of Google, front and center with WizOS leading the security story with its hardened container base images. On May 12, Red Hat used its Summit keynote slot to GA Red Hat Hardened Images. A week later at Open Source Summit North America, Edera and Minimus announced a partnership bundling hardened images with hypervisor-level workload isolation.
So, what’s going on here? If you ask my colleague James Governor he would likely point you to his LinkedIn post from last year where he wrote “talking to Chainguard. dear lord they’ve apparently established a license to print money”—a sentiment he then expanded into a blog post. But in addition to the possibly obvious financial motive, it is worth exploring this exploding market for hardened images in light of rapidly improving LLMs. Container base images create a centralized supply chain risk surface, yet the inherited vulnerabilities they introduce are often pushed downstream to developers who have little practical ability to remediate them—thus, the need for subscription-based solutions.
So let’s talk about image hardening in 2026. Why hardened images blew up, why images don’t come pre-hardened, and why developers are paying attention.
What does “hardened” even mean?
When practitioners say “hardened image” in 2026, they usually mean a number of properties mapping closely to what the major security-standards bodies have been recommending for years. The foundation is a minimal base, often distroless, so there’s no shell, no package manager, and little else for an attacker to live off. This is the oldest and least controversial piece: NIST’s container security guidance, SP 800-190 recommends base layers be minimalistic distributions with the OS kernel omitted, noting that a stripped-down image yields a much smaller attack surface with fewer opportunities to attack and compromise it. On top of that base sit a handful of runtime hardening defaults: a non-root user, and a read-only root filesystem where the workload allows. Both trace back to the same NIST guidance, which calls for least-privilege execution and describes the read-only filesystem design as a way to keep an attacker from persisting data inside the image.
The remaining pieces are about provenance and upkeep. A hardened image is expected to ship with an SBOM enumerating its contents—what CISA, building on the original NTIA work, defines as a formal record of the components and supply-chain relationships used in building software—and with some form of cryptographic provenance, typically signed attestations following the OpenSSF’s SLSA framework, which specifies cryptographically signed provenance generated by the build system to detect tampering (in practice, often via Sigstore Cosign). Finally, there’s a maintenance promise in the form of a service-level commitment that whoever ships the image will rebuild and republish it when an upstream CVE lands. This last element is the newest and the least standardized; it’s where commercial “secured image” offerings go beyond the baseline, with vendors like Wiz describing images that are continuously maintained at near-zero CVEs under an SLA.
Why now?
Three primary pressures converged to make 2026 the year of image hardening.
The first is that the National Vulnerability Database stopped being a reliable single source of truth. CVE submissions grew 263% between 2020 and 2025, with Q1 2026 running another third higher year-over-year. NIST enriched almost 42,000 CVEs in 2025 (a 45% jump over its previous record) and still could not keep up. On April 15 they formally moved to a prioritized model. Only CVEs on CISA’s KEV catalog, in federal software, or in executive order 14028 critical software get full Common Vulnerability Scoring System (CVSS) scoring and CPE mapping. Everything else gets a “Not Scheduled” label. VulnCheck’s analysis puts ”approximately 10,000 vulnerabilities from 2025 without a CVSS score.” If your scanner used to tell you what to prioritize based on the National Vulnerability Database (NVD), that pipeline has a hole in it now.
The second pressure is that the open source registries are openly under siege. The Shai-Hulud worm started chewing through npm packages in late 2025, came back as a more aggressive 2.0 in November, and in April 2026 a variant called Mini Shai-Hulud started compromising packages with valid OIDC-signed provenance, slipping past 2FA entirely. By May 11 it had hit TanStack (12 million weekly downloads on React Router alone), Mistral AI, UiPath, and OpenSearch. OpenAI disclosed credential theft from two employee workstations. TeamPCP, the group behind much of it, open-sourced the worm and announced a $1,000 contest for the largest supply-chain attack built on top of it. The attack surface is no longer just your package.json. It is every package any base image pulls in by default.
The third pressure is that AI is doing vulnerability discovery at machine speed. Anthropic released Claude Mythos to vetted security researchers as part of its Project Glasswing. OpenAI did the same with GPT-5.4-Cyber. The Edera-Minimus announcement was explicit about why the timing mattered, referencing Mythos by name. Whatever you think of threat-intel framing, the empirical claim is straightforward: novel vulns are being found and weaponized faster than human-scale CVE triage can absorb them.
So where do hardened images come into this? While image hardening does not solve any of these problems individually, it shrinks the surface that all three of them attack.
How we got here
Container images started out as the worst version of themselves, on purpose. Early Docker tutorials taught developers to build containers on top of a full Linux distribution like Ubuntu or Debian. You got a familiar filesystem, a shell, a package manager, and the ability to debug a running container with the same tools you use on your laptop. That convenience came with everything else the distribution shipped, useful or not, and base images stayed bloated for years.
Google’s distroless project was the first serious push in the other direction, starting around 2017. The idea was stark: ship your app and its runtime dependencies and absolutely nothing else. No apt. No sh. Bazel built it. The smallest distroless image is about 2 MiB, roughly half the size of Alpine and less than 2% the size of Debian. Adoption has been significant. The Kubernetes ecosystem treated distroless as best practice, and it has been “employed by Google and other tech giants.”
Chainguard, founded in 2021 by several ex-Google engineers (including the people who built Sigstore), came at it from a different angle. They built Wolfi, a Linux “(un)distro” designed specifically to be the building block for hardened images rather than a general-purpose OS. Apk-based, no kernel, packages compiled with hardening flags, SBOMs at build time, Sigstore signatures on everything. By February 2026 they had passed 500 million unique container build manifests and a catalog of more than 2,000 projects, on roughly $40 million in 2025 ARR.
There have been several other approaches to the problem that hardened images address, each tackling a different layer of the stack. Notably, AWS’s Bottlerocket is a hardened host operating system rather than a hardened application image. It minimizes the attack surface of the underlying node by shipping only the components needed to run containers, but it leaves the security of the application images themselves up to the user. A closer analogue is Replicated’s SecureBuild, which targets the application layer directly by providing zero-CVE container images for open source software. Rather than repackaging upstream binaries, SecureBuild rebuilds everything from source using an ephemeral build system and distributes the results through a hardened registry. Notably, Replicated also shares a majority of image subscription revenue with the open source maintainers whose projects it secures. Taken together, these efforts illustrate that “hardening” can happen at multiple points, from the host OS down to the individual application image, and that the most effective strategy often depends on which part of the supply chain poses the greatest risk.
What developers actually care about
A base image is a shared dependency, which means it’s also a shared liability. Whatever vulnerabilities ship inside an image are inherited by every application built on top, and they land on developers who are rarely in a position to fix them. You can’t patch a flaw in a system library you didn’t choose and often don’t control. The gap between who inherits the risk and who has the will and ability to actually remediate it is the whole reason a market for subscription-based hardened images exists.
The mechanism behind that liability connects directly to the flood of CVEs that AI-assisted vulnerability discovery has unleashed. Every package inside an image is a line in its SBOM and, potentially, a vulnerability waiting to be surfaced. A container built on a full Ubuntu base carries ~100 packages before your code is even added, and some of them—the shell, the package manager, assorted system libraries—never execute at runtime. Yet each is still a row your scanner checks against the vulnerability databases, and each can light up red when a new CVE lands upstream. Distroless skepticism aside, a distroless image cannot inherit a software vulnerability that it doesn’t contain. Stripping the image down was never really about disk size; it was about carrying less code that can turn into a CVE in the first place.
Why isn’t “hardened” already the default?
As I have been following the image hardening market in vendor briefings and conference keynotes, the question of why hardening isn’t the standard was one I struggled with. Here’s what I learned: container base images grew up as a developer convenience tool, not a security artifact. Installing extra packages from the command line is one of the first things any Docker tutorial teaches—Docker’s own Dockerfile guide includes apt-get install—and many of the most popular official images ship a full toolchain by default, with -slim and -alpine variants offered precisely because the defaults carry more than most workloads need, and changing them would have broken enough downstream workflows that it was never going to be a routine upstream decision.
There is also an incentive split. The upstream distribution maintainers and the developers using their images are different people with different priorities. Debian wants to ship a usable general-purpose OS. The developer pulling the Debian Bookworm OS into a container wants a runtime for one specific application. Hardening for the second use case requires throwing out things the first use case depends on. Vendors stepped in because upstream maintainers generally lack strong enough incentives to harden on the downstream user’s behalf. Docker, Chainguard, Minimus, Google/Wiz, and Red Hat all appearing in roughly the same window is the industry’s attempt to make hardened the new default without waiting for upstream to change.
Conclusion
To sum up, the reason behind 2026’s influx of hardened images is the increasing cost of extraneous code: transitive dependencies, unused packages, etc. As automated tooling drives up the rate of vulnerabilities, both publicly disclosed and black market exploits, the triage pipeline is necessarily straining under the volume, so that it has ceased to be a tolerable annoyance for developers, and has graduated into a serious liability. With increasingly malicious supply chain worms targeting the build pipeline directly, with AI accelerating both sides of the discovery-exploitation cycle, the price of shipping a whole distribution’s worth of software inside every container went up. Hardened images are the market finally pricing that in.
Disclaimer: Docker, Red Hat, Bitnami by VMware/Broadcom, Google, AWS, and Chainguard are all RedMonk clients.