Chainguard Review 2026: Hardened Container Images and Zero-CVE Supply Chain Security

Your containers are probably riddled with vulnerabilities you didn't put there.

Not because your developers are careless. Not because your security team is asleep at the wheel. Because the base images your software is built on — those official-looking images from Docker Hub — are full of packages you're not using, libraries nobody's auditing, and CVEs that accumulate faster than anyone can patch them. You're inheriting someone else's mess every time you run `docker pull`.

Chainguard exists to fix that problem at the root. It builds and maintains a catalogue of hardened, minimal container images based on its own Linux distribution, Wolfi. The pitch is stark: fewer packages means fewer CVEs. No unnecessary tooling means no unnecessary attack surface. And with cryptographic attestations and software bill of materials (SBOM) generation baked in, you can actually prove what's in your software — not just assume.

This is not a developer convenience tool. This is infrastructure-level security for teams who have reached the point where "our Docker images are fine" is no longer an acceptable answer.

What Chainguard Actually Does

Chainguard operates at the foundation of the software supply chain. Rather than scanning images after they've been built (the approach most security tools take), it changes what's in those images in the first place.

Chainguard Images are the flagship product: a curated library of hardened, minimal container images for common runtimes and tools — Python, Node, Go, Java, Nginx, PostgreSQL, and hundreds more. These images are built from Wolfi, Chainguard's purpose-built Linux distribution, which strips out everything that doesn't need to be there. The result is images that contain dramatically fewer packages, and therefore dramatically fewer CVEs.

The zero-CVE claim deserves scrutiny, because it sounds like marketing. The reality is more nuanced: Chainguard's images are continuously rebuilt against the latest patched versions of every component. They don't claim a given image will never have a CVE — they claim that at any given time, they are working to ensure their images have zero known CVEs. When a CVE is disclosed, Chainguard patches and rebuilds, often faster than upstream maintainers. For many images, this means genuinely zero CVEs when scanned on the day you pull them.

Wolfi OS is the underpinning that makes this possible. It's a container-native Linux distribution built with security from the ground up: packages are individually signed, every build is reproducible, and there's no assumption that the environment running the container is trusted. Wolfi borrows ideas from Alpine (small, minimal) but adds proper glibc support (which matters for compatibility) and a much more rigorous package management pipeline.

SBOM Generation is automatic. Every Chainguard image ships with a software bill of materials, describing exactly what packages are present and at what versions. These are generated in standard formats (SPDX, CycloneDX) and signed with Sigstore — the open standard for supply chain signing that's rapidly becoming the default across the industry. This is not a checkbox feature. If you need to demonstrate compliance (SOC 2, NIST SSDF, EO 14028 in the US context), having cryptographically verifiable SBOMs for every image in your pipeline is significant.

Cosign and Sigstore Integration means that every image Chainguard publishes can be verified before you use it. You can confirm that the image you're pulling is exactly what Chainguard built, that it hasn't been tampered with in transit, and that it matches the corresponding SBOM. For teams operating in regulated industries or with strict supply chain requirements, this is the kind of provenance that auditors actually want to see.

Chainguard Enforce (now part of the broader platform) provides runtime policy enforcement — the ability to define rules about what images can run in your Kubernetes clusters and automatically block anything that doesn't meet your security standards. Think of it as a gatekeeper for your container runtime, ensuring that the care you took at build time isn't undone by someone running an old image in production.

Pricing

Chainguard's pricing has two primary tiers, with enterprise contracts on top.

The free tier is genuinely useful — you can replace your Docker Hub base images with Chainguard equivalents at no cost, and immediately reduce your CVE exposure. The commercial tiers unlock the full catalogue (particularly important if you're running less common runtimes), private image variants, and the policy enforcement tooling.

Pricing is not fully transparent on the website, which is a common frustration with enterprise security vendors. For serious deployments, expect a sales conversation before you get to a number.

Comparison: Chainguard vs. Docker Hub, Snyk Container, and Anchore

The key distinction is philosophy. Docker Hub tells you what's wrong after you've already pulled an insecure image. Snyk Container scans your images and suggests fixes. Anchore helps you enforce policies. Chainguard changes what's in the image before any of that is necessary.

That said, these tools are not mutually exclusive. Many mature security programmes use Chainguard images as their base and Snyk or Anchore on top for ongoing scanning and policy enforcement. Defence in depth.

Who It's For

Engineering teams at scale. If you're running dozens of services in Kubernetes and your security scanner produces hundreds of CVE findings every sprint, most of which are noise from packages nobody uses, Chainguard images will materially reduce that alert burden. Less time triaging CVEs means more time building.

Regulated industries. Financial services, healthcare, legal tech, defence adjacent — anywhere that a compliance framework requires you to demonstrate what's running in your environment. Chainguard's SBOM generation and Sigstore attestations are built for exactly this kind of audit requirement.

Teams responding to board-level supply chain concerns. Post-SolarWinds, post-Log4Shell, post-XZ Utils, software supply chain security is now a board conversation in many organisations. Chainguard gives you something concrete to point to.

Startups building security into their architecture early. The free tier means there's no cost reason not to start using hardened images from day one. Building on a secure foundation from the start is always cheaper than retrofitting.

Who It's Not For

Very small teams with minimal container usage. If you're running two or three services and your threat model is "we're not interesting enough to target," the operational overhead of adopting Chainguard's tooling may not be worth it yet.

Teams without Kubernetes or container orchestration. Chainguard's value compounds when you have consistent image pipelines and can enforce policies at scale. If your containers are ad hoc, the benefit is narrower.

Anyone expecting a drop-in replacement with zero adjustment. Chainguard's images are minimal by design. Applications that expect certain binaries or tools to be present in the base image (bash, curl, package managers) may need adjustment. This is a feature, not a bug, but it requires engineering effort.

Teams looking for a pure scanning solution. If you want something that drops into your CI/CD pipeline and flags issues without changing your base images, Snyk or Semgrep are more immediately accessible. Chainguard requires a more fundamental infrastructure decision.

How to Get Started

Week 1: Replace one base image. Pick a low-risk service and swap its base image for the Chainguard equivalent. Run your existing scanner against both the old and new image and compare CVE counts. The difference will make the case for you. Start with `cgr.dev/chainguard/python` or `cgr.dev/chainguard/node`.

Week 2: Verify your SBOMs. Pull the SBOM for your new Chainguard image using the Cosign CLI: `cosign download sbom cgr.dev/chainguard/python:latest`. Walk your security team through what it contains. If you're working toward any compliance certification, document this as part of your evidence.

Week 3: Expand to critical services. Identify the services that handle the most sensitive data or face the public internet. Prioritise those for Chainguard images. Keep your scanner running on everything — Chainguard images are minimal, not infallible.

Month 2+: Evaluate Enforce. Once you're comfortable with the images, explore whether runtime policy enforcement makes sense for your environment. This is where Chainguard's value proposition becomes most complete — you can guarantee that the only images running in your clusters are the ones you've approved.

The Honest Assessment

Chainguard is doing genuinely important work. The software supply chain problem is real, it's worsening, and the industry's default response — "scan everything and triage the findings" — is not scaling. Building security upstream, at the image level, is the right instinct.

The zero-CVE narrative is compelling but requires clear-eyed interpretation. "Zero CVEs at time of pull" is not the same as "zero CVEs forever." Chainguard images still need to be kept current. Your scanning programme should still run. But the baseline they start from is orders of magnitude cleaner than a typical Docker Hub image.

The main friction points are real: minimal images require engineering effort to adopt, pricing transparency could be better, and the full platform value only becomes apparent at scale. This is not a tool you deploy in an afternoon and declare victory.

But if you are serious about supply chain security — and in 2026, you should be — Chainguard belongs in your architecture conversation. It's not just another security scanner. It changes the problem.

Digital by Default helps businesses identify, evaluate, and implement the right AI and security tooling for their specific context. If you're trying to reduce container CVE exposure, meet supply chain compliance requirements, or just want an honest assessment of where your infrastructure security stands, [get in touch](/contact).