Chainguard Images: Minimal and Signed Images
Table of contents
- Key takeaways
- What they offer
- Typical usage: multi-stage Dockerfile
- Verification with cosign
- Size comparison
- Chainguard vs Alpine
- When it makes sense to adopt Chainguard
- Pricing and tiers
- Conclusion
- Frequently asked questions
- How do I debug a Chainguard container if the image has no shell?
- Can I use Chainguard Images for free in production?
- What advantage does Chainguard have over Alpine if both are minimal images?
- Sources
Chainguard Images are minimal Docker containers from the company behind Sigstore, with zero known CVEs, Cosign-signed SBOMs and daily rebuilds on top of Wolfi, its own glibc-based distribution. They pay off over official images when strict compliance, supply chain audits or sensitive production workloads are at stake.
Chainguard[1] is the company founded by Sigstore’s creators, focused on practical supply chain security. Its main product is Chainguard Images: Docker images built with extreme rigour, with zero known CVEs, signed SBOMs and reproducible builds out of the box. For enterprises with strict compliance or wanting to reduce attack surface, they are a serious alternative to debian:latest or alpine:latest.
Key takeaways
-
Zero known CVEs at publication time: images are rebuilt daily.
-
Sigstore/Cosign-signed SBOMs included out of the box: cryptographic verification without extra steps.
-
Based on Wolfi, Chainguard’s own glibc distribution, avoiding Alpine’s musl incompatibilities.
-
The free tier covers the most popular
latestimages; pinned versions and SLA support are enterprise. -
Distroless without a shell is the production variant; the
-devvariant adds build tools for multi-stage use.
What they offer
Every Chainguard image has traits that set it apart from official Docker Hub images:
-
Minimal: only what the application needs to run. No bash, no package manager, no debugging utilities that widen the attack surface.
-
Zero known CVEs: rebuilt daily; when a vulnerability appears, the fix ships in hours, not months. This complements (it does not replace) continuous scanning with tools such as Trivy or Grype.
-
Signed with Sigstore: any CI system can verify the signature before using the image.
-
Automatic, signed SBOMs: you know exactly which packages are inside and at which version.
-
Reproducible builds: given the same input, the output hash is deterministic, in line with the provenance levels defined by SLSA.
Typical usage: multi-stage Dockerfile
FROM cgr.dev/chainguard/node:latest-dev AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci && npm run build
FROM cgr.dev/chainguard/node:latest
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]
Result: ~100 MB runtime vs ~200-300 MB official Node. No shell, no npm, no wget, no curl in production.
Verification with cosign
cosign verify cgr.dev/chainguard/node:latest
--certificate-oidc-issuer=https://token.actions.githubusercontent.com
--certificate-identity-regexp='.*chainguard.*'
This cryptographic verification closes the loop between who built the image and which pipeline was used. It is compatible with Kubernetes admission-control policies via Kyverno or Gatekeeper. To integrate this verification into the full pipeline, see also practical DevSecOps with Sigstore and cosign.
Size comparison
| Stack | Official | Alpine | Distroless | Chainguard |
|---|---|---|---|---|
| Node 20 | 1.1 GB | 180 MB | 180 MB | 170 MB |
| Python 3.12 | 1 GB | 170 MB | 200 MB | 170 MB |
| nginx | 187 MB | 40 MB | N/A | 35 MB |
| Go runtime | N/A | N/A | 70 MB | 50 MB |
Comparable in size to Google’s Distroless, but with active daily CVE management and SBOMs included.
Chainguard vs Alpine
| Aspect | Chainguard | Alpine |
|---|---|---|
| Base system | Wolfi (glibc) | musl + BusyBox |
| CVE management | Proactive, daily | Community |
| SBOMs | Included, signed | Not native |
| Compatibility | Full glibc | musl (can break) |
Alpine uses musl libc, which occasionally causes subtle incompatibilities with apps designed for glibc: DNS resolution issues, locale handling, threading quirks. Chainguard uses Wolfi with standard glibc, which eliminates that whole class of incidents.
When it makes sense to adopt Chainguard
It makes sense to adopt when:
-
The organisation has strict compliance requirements (PCI-DSS, HIPAA, FedRAMP) and needs auditable pipelines.
-
Supply chain security is a high priority on the security roadmap.
-
CVE reduction is an ESG reporting or audit metric.
-
Production workloads handle sensitive data where the blast radius of a compromise matters.
It makes less sense when:
-
These are personal projects or experiments where the overhead is not worth it.
-
The app has legacy dependencies specific to glibc that are not covered by the Wolfi catalogue.
-
The team lacks the capacity to manage the lifecycle of pinned images.
Pricing and tiers
The free public tier covers the latest images of the most popular stacks with daily updates. The enterprise tier adds:
-
Pinned-version images (
cgr.dev/chainguard/node:20). -
SLA-backed support.
-
Custom images for internal stacks.
-
FIPS-certified variants for government environments.
To get started and evaluate the impact on CVE count, the free tier is enough.
Conclusion
Chainguard Images represent where the enterprise container ecosystem is heading: minimal, signed, updatable, auditable. For companies with compliance requirements or that value serious supply chain security, the cost of migrating pays for itself in reduced audit work and better risk metrics. The free public tier allows commitment-free evaluation. Against Docker Hub’s official "latest" images, the difference in CVE count and risk profile is measurable from the first scan.
Frequently asked questions
How do I debug a Chainguard container if the image has no shell?
Not inside the production image, which by design ships without bash, a package manager or utilities such as wget or curl. The pattern is a multi-stage Dockerfile: the -dev variant (for example cgr.dev/chainguard/node:latest-dev) includes the build tools and is used to compile, and the runtime image cgr.dev/chainguard/node:latest only receives the artefacts. The result is around 100 MB versus 200-300 MB for the official Node image.
Can I use Chainguard Images for free in production?
Yes, with caveats. The free public tier covers the latest images of the most popular stacks with daily rebuilds, enough to get started and measure the impact on CVE count. Pinned-version images such as cgr.dev/chainguard/node:20, SLA-backed support, custom images for internal stacks and FIPS-certified variants belong to the enterprise tier. If your team cannot manage the lifecycle of pinned images, the free tier may be limiting.
What advantage does Chainguard have over Alpine if both are minimal images?
The libc and the CVE management. Alpine uses musl and BusyBox, and musl occasionally causes subtle incompatibilities with applications designed for glibc: DNS resolution, locale handling or threading quirks. Chainguard is based on Wolfi with standard glibc, which eliminates that whole class of incidents. On top of that, images are rebuilt daily with fixes landing in hours, include Sigstore/Cosign-signed SBOMs and are reproducible, whereas Alpine's CVE management is community-driven.