TL;DR Wolfi OS is an open-source, container-first undistro designed around SBOMs, provenance, and daily rebuilds. Combined with Chainguard’s free-tier images, it is a credible answer to FIPS/FedRAMP image rebuild mandates — and the entire open-source path can be evaluated and operated without any commercial commitment. This is Part 2 of the series. Part 1 sets up the vocabulary.

Building from source

Why Wolfi Ticks the Security Boxes

The prerequisites we established in Part 1, mapped to how Wolfi handles each:

  • SBOM for every package and image — built-in, SPDX format, attached to the artifact
  • Signed artifacts — Sigstore/cosign signatures by default
  • Minimal attack surface — no shell, no package manager in runtime images
  • Rapid CVE response — daily rebuilds of the entire catalog, not quarterly
  • glibc path for FIPS crypto — compatible with FIPS-validated OpenSSL and BoringSSL
  • SLSA-aligned provenance — attestations emitted at build time
  • Reproducible builds — hermetic, auditable, and verifiable
  • Transparent, open-source build process — everything is in public GitHub repos
  • APK signing with verifiable chains — package integrity is enforced end-to-end Each of those bullets would have been its own engineering project to bolt onto a traditional base image. On Wolfi they are the defaults.

How Chainguard Creates Container Images with Low-to-No CVEs

The insight that makes the low-CVE claim more than marketing: most CVEs in your images are stale packages, not newly disclosed vulnerabilities. If you rebuild against the latest upstream sources every day, the window in which a freshly disclosed CVE lives in your images shrinks from weeks to hours.

Chainguard rebuilds its entire library and image catalog on a daily cadence. That cadence is only feasible because the build system is fully automated, reproducible, and gated by tests. No manual patching. No “we’ll pick it up next sprint.” The rebuild is the patch mechanism.

Their public write-up on how this works is worth reading in full — it is one of the clearest operational explanations of a working supply chain security model I’ve seen.

The wolfi os logo

Free Tier vs. Commercial — An Honest Map

One of the reasons I like writing about Wolfi is that the open-source and commercial paths are genuinely separable. You can evaluate the entire system, and operate it in production, without any commercial commitment.

The fully open-source path — you can build the entire system yourself:

  • Wolfi OS itself — Apache 2.0, fully open

  • apko and melange — Apache 2.0, build your own image catalog end-to-end

  • Public Chainguard images on cgr.dev/chainguard/* (developer variants)

  • Documentation at docs.chainguard.dev — genuinely one of the best in the cloud-native space right now, and treated as a first-class product rather than an afterthought If you want to go further, Chainguard’s commercial offering adds:

  • Enterprise support SLAs

  • Private image mirrors and longer version retention

  • FIPS-specific hardened variants

  • Centralized vulnerability and compliance reporting The practitioner take: evaluate the open-source path first. You can validate the full Wolfi + apko + melange + cosign workflow end-to-end without spending a dollar. If operational overhead or compliance scope outgrows what you want to self-manage, the commercial path is there — but it should be a deliberate next step, not a default assumption.

Our Evaluation Approach

Rather than a big-bang migration, we are running a scoped evaluation. The shape of it:

Evaluation approach

  1. Pick a representative slice. Python, Node, Go, and JVM runtimes, plus two or three internal builder images. Enough variety to exercise the real integration surface.
  2. Measure what matters. CVE delta (before/after), image size delta, SBOM completeness, signing status, and build time delta. Numbers, not vibes.
  3. Validate the FIPS path. Confirm that the crypto libraries in the rebuilt images align with the client’s validated-module requirements.
  4. Test the deploy loop. Wire up cosign verification in the admission controller and make sure unsigned images are actually rejected.
  5. Document the rough edges. Package-name differences, missing packages we had to build ourselves with melange, Dockerfile patterns that need to change. That last point is where most of the real work lives.

What I’d Tell a Peer

A few things I would pass to anyone walking into this evaluation:

  • Wolfi is not a drop-in Alpine replacement. Expect package-name and path differences. Budget time for a compatibility pass.
  • melange has a learning curve but pays off the first time you need to build a package upstream does not ship.
  • The security posture improvement is real and measurable. CVE counts drop, image sizes shrink, and the attestation chain becomes something you can actually point an auditor at.
  • Don’t skip the admission controller step. Building signed images without verifying them at deploy time leaves the enforcement loop open.
  • Using Wolfi and using Chainguard’s commercial offering are separable decisions. Start with the open-source stack and let your operational needs drive the next step.

Wrap-Up

FIPS and FedRAMP did not invent supply chain security; they just made it non-optional. The good news is that the open-source tooling has caught up. Between Wolfi, apko, melange, Sigstore, and the scanning ecosystem from Part 1, you can assemble a serious, auditable image pipeline today — and decide later whether the operational math favors self-managing it or buying support.

If you found this series useful, Part 1 is here. If you are already down this path and seeing things differently, I want to hear about it.

📖 Further Reading