Zero CVEs by default is a floor, not a moat

Every base image in your registry is somebody else's build farm output that you agreed to run in production. Cheerful, isn't it. This week Docker's marketing team would like you to stop worrying about that, because zero CVEs is the new default and their Hardened Images catalog will handle it. There is a real argument in there. There is also a shape of thinking that got us into the current mess.

The post, published this week on the Docker blog, opens with Docker's CISO Mark Lechner arguing that this year's supply-chain compromises are a permanent shift in the threat landscape. He is right. Trivy and KICS, tools whose entire job is to tell you about compromised software, were themselves compromised this year. When your scanner is the delivery vehicle, "green build" stops meaning what it used to.

The pitch, plainly

Docker Hardened Images (DHI) is a catalog of minimal, source-built container images with SLSA Build Level 3 provenance and signed SBOMs. The catalog is free for developers. It ships Alpine- and Debian-compatible variants, so swapping a base image is meant to be a one-line change in the Dockerfile rather than a rewrite.

The post also announces Extended Lifecycle Support that patches end-of-life packages for up to five extra years, Rego-based policies inside Docker Scout, hardened Helm charts, hardened MCP servers, and a Terraform provider for customization at scale. If you are still consuming a raw upstream distro-slim image in production because refactoring your base layer never got prioritized, this is a defensible upgrade. Fewer packages. No shell. Provenance you can actually verify. That is the honest floor.

Where the pitch gets thin

The thin part is the word "default." A default is what happens when nobody is paying attention. Supply-chain security only works when somebody is paying attention.

A hardened image with an attestation you never check is a normal image with extra branding. A signed SBOM that lives on a registry but never gets diffed against yesterday's SBOM tells you nothing. A zero-CVE report from a scanner whose release train got backdoored is worse than a red report, because red at least prompts a human. This is the trust boundary the industry keeps sliding past. You can outsource the image. You cannot outsource the verification.

The post itself frames the model as additive: your builds, your tools, your pipelines stay the same. That is a feature for adoption and a problem for security posture. If nothing in your pipeline changes when you switch base images, the interesting question is what your pipeline was checking before, and the answer is usually the exit code of a scanner.

Kick the tires

The right response to a "secure by default" announcement is a checklist, not enthusiasm. Five questions worth asking before you rewrite anyone's FROM line:

1. Does your build fail closed when the SBOM attached to a base image is missing, unsigned, or stale relative to the image digest sha256:<digest>?
2. Do you re-verify provenance on pull, or only at initial ingest? A cached image is only as trustworthy as the last time you actually re-checked its attestation.
3. Which key material is your verifier trusting? If it is a single vendor's public key, that vendor is now inside your trust boundary.
4. Do you diff the SBOM of every new base tag against the previous one, and does the delta go somewhere a human on-caller reads?
5. When your scanner or hardened-image vendor gets popped (they will, eventually), how many hours do you need to invalidate every image built while the poisoned release was in your CI cache?

None of that is Docker's job to answer for you. It is also not the kind of work a "make zero CVEs the default" headline invites you to do.

How the rest of the market handles the same job

The zero-CVE base image market is not a monoculture, and neither is the CI-side story of getting one into production safely.

• Chainguard Images ship a similar zero-known-CVE promise on top of Wolfi, with per-image provenance and aggressive patch cadence. If the specific thing you want is a source-built undistro with Cosign-native verification, Chainguard is honestly the better fit.
• Google Distroless is still the minimal, no-frills option many teams already run. No vendor, no SLA, no bill. If you can live with community-cadence updates it is the cheapest floor available.
• Red Hat Universal Base Image (UBI) Micro is what you reach for when the compliance conversation ends with "must be Red Hat." Different trust root, similar goal.
• GitHub Actions ships native build provenance attestations and Sigstore-backed artifact signing inside workflows most teams already run, which handles the "prove where this artifact came from" half of the problem without adding a separate tool.
• GitLab CI bundles SBOM generation and dependency scanning into the pipeline templates, which reduces the number of separate vendors in your chain, useful because every added tool is a fresh compromise vector.
• Buddy (buddy.works) is action-based rather than YAML-first, so pinning a base image, running an SBOM diff step and refusing to deploy on a signature mismatch is a matter of chaining three discrete actions. One option among several; reach for it if you already dislike hand-editing pipeline YAML for every new gate.

Notice how none of these makes "zero CVE by default" true on its own. They all make it easier to check.

The kicker

Docker is right that hardened base images should be the default. They are also right that the threat model changed for keeps. The uncomfortable half of the same argument is that "default" cannot mean "unattended." A signed SBOM you never open is a candle you never lit. Take the hardened image. Take the free catalog. Then wire the verification step into the boring part of your pipeline, and refuse to ship when it fails. That is the actual moat. The rest is a floor.