In September 2022, Chainguard open sourced a Linux distribution that its own engineers refuse to call a distribution. Wolfi, they said, is an "undistro" — a community-governed package repository purpose-built for assembling minimal, low-CVE container images, not for booting a general-purpose machine. There's no ISO to download, no default kernel, no desktop environment, and no versioned release train like Ubuntu 22.04 or Debian 12. Instead, Wolfi ships a continuously rebuilt set of glibc-based packages, assembled into OCI images with tools called melange and apko, with every build carrying a signed SBOM. For any platform or security team evaluating Chainguard Images, Wolfi is the foundation sitting underneath — and understanding how the "undistro" actually works, who really governs it, and where it creates blind spots matters before a production pipeline depends on it. Here's what the marketing language leaves out.
What Is Wolfi, And Why Does Chainguard Call It An "Undistro"?
Wolfi is a Linux package repository designed exclusively for building container and cloud-native images — not a bootable operating system in the traditional sense. Chainguard's engineering team introduced it in September 2022, explicitly rejecting the "distro" label because Wolfi has no installer, no default kernel package most users touch, and no fixed release cadence. Traditional distros like Debian or Fedora ship a coherent, versioned snapshot of packages every year or two; Wolfi instead behaves like a rolling repository that CI pipelines pull from continuously, similar in spirit to how a package registry like npm or PyPI works rather than how an OS ships.
The point of the exercise is narrow and intentional: give teams a source of packages they can compile into distroless, minimal images with an auditable software bill of materials attached to every build. That framing — "not a distro, an undistro" — is also a useful marketing distinction for Chainguard, since it positions Wolfi as a new category rather than a competitor to Alpine or Debian, even though in practice it replaces them as a base image source in a Dockerfile's FROM line.
How Does Wolfi Differ From Alpine Linux Or Debian?
Wolfi differs from Alpine primarily in its C library and from Debian in its release model. Alpine Linux, the long-standing default for minimal container images, uses musl libc, which breaks compatibility with some glibc-compiled binaries — a recurring pain point for Node.js native modules, Python wheels, and JVM-based tooling. Wolfi uses glibc instead, trading a small amount of image size for broader binary compatibility, which is arguably its single biggest practical advantage over Alpine for polyglot production stacks.
Against Debian and Ubuntu, the difference is the release model. Debian 12 "Bookworm" and Ubuntu 24.04 LTS are fixed, versioned snapshots patched on a defined schedule for years. Wolfi has no LTS concept at all — packages are rebuilt from source on an ongoing basis, and a security fix that lands upstream is typically available as a new Wolfi package within hours to a day, not on the next point release. Combined with apko's ability to assemble images with no shell, no package manager, and no unnecessary binaries baked in, this is why Chainguard Images built on Wolfi routinely score "0 known CVEs" on scanners like Grype at publish time — there's simply very little installed surface left to have a CVE against.
Is Wolfi Actually Community-Governed, Or Is It Chainguard's Project With An Open License?
Wolfi is Apache 2.0 licensed and hosted in the open wolfi-dev GitHub organization, but in practice it functions much closer to a vendor-led project than an independent community effort. The build infrastructure, signing keys, package review process, and the overwhelming majority of commits are run by Chainguard employees, and Chainguard is explicit that Wolfi exists to feed its commercial Chainguard Images product — the paid tier that adds FIPS-validated variants, extended CVE remediation SLAs, and enterprise support contracts on top of the same underlying packages.
That's not unusual as an open-source pattern — it resembles how Fedora relates to Red Hat Enterprise Linux, or how Google stewards several CNCF projects it also sells managed versions of. But it means "community" should be read as "open license and open contribution process," not "governed independently of the vendor selling support for it." If Chainguard's roadmap shifts, forking Wolfi's signing infrastructure and rebuild pipeline is a materially harder lift than forking a GitHub repo, which matters for any team weighing long-term lock-in against Alpine or Debian's more distributed governance.
Why Do Wolfi-Based Images Report Zero Or Near-Zero CVEs?
Wolfi-based images report few or no CVEs mainly because there's almost nothing installed to have a CVE against, not because the software inside is inherently more secure. Distroless-by-default apko builds strip out shells, package managers, and libraries an application doesn't explicitly declare, which shrinks the attack surface scanners actually inspect. Combine that with rebuild cycles measured in hours rather than the multi-week patch windows common on older LTS base images, and a "0 CVEs" badge in a scan report becomes achievable in a way it rarely is on a stock Ubuntu or Debian base.
The catch is that this is a snapshot claim, not a durable guarantee. NVD published tens of thousands of new CVEs across 2024 alone, and a rolling-release base can drift from what was scanned in CI by the time an image is actually deployed days or weeks later — a gap that versioned, pinned distros don't have in the same way, since teams control exactly when they move to a new release. More importantly, the OS layer was rarely where the real damage came from anyway: incidents like Log4Shell (CVE-2021-44228) lived in an application dependency, not an operating system package, and no base image choice — Wolfi included — protects against vulnerable code your own build pulls in from npm, PyPI, or Maven.
What Are The Trade-Offs Of Betting Production Workloads On Wolfi?
The trade-offs center on reproducibility, maturity, and tooling lock-in rather than security itself. Because Wolfi has no versioned or LTS releases, "pin the base image and audit it once" — a standard move for SOC 2 or FedRAMP evidence gathering on Debian or Ubuntu — doesn't map cleanly onto a repository where the package set underneath a tag can change daily. Teams either pin to a specific image digest and accept they'll fall behind on patches, or track latest and accept that what passed a compliance review last month may not be byte-for-byte what's running today.
Wolfi is also young relative to the distros it's replacing — Debian dates to 1993, Alpine to 2005, Wolfi to 2022 — which means a smaller base of community troubleshooting knowledge, fewer Stack Overflow answers, and a learning curve around melange and apko for teams used to plain Dockerfiles with apt-get or apk add. None of that is disqualifying, but it's a real cost that "0 CVEs" marketing tends to leave out of the conversation.
How Safeguard Helps
Whichever base image strategy a team lands on — Wolfi, Alpine, Debian, or a mix across services — the questions that actually matter for supply chain security are the same: what's really running in production right now, does it match what was scanned and signed in CI, and can that be proven to an auditor without manual spreadsheet work. Safeguard is built to answer those questions independent of any single vendor's base image or attestation stack.
Concretely, Safeguard continuously ingests and verifies SBOMs generated by melange, apko, or any other builder, and cross-checks in-toto and SLSA provenance attestations against expected signing identities rather than trusting a green checkmark at face value. Because Wolfi's rolling-release model means the image scanned in CI can drift from what's deployed days later, Safeguard tracks that drift directly — flagging when a running workload no longer matches its last verified build — instead of relying on a point-in-time scan result. And because the real exploited risk usually sits in application dependencies rather than the OS layer, Safeguard's policy engine evaluates CVE exposure and license risk across both layers together, so a "0 CVEs" base image claim doesn't create a false sense of coverage for the npm, PyPI, or Maven packages actually shipping the vulnerable code.
That vendor-neutral posture matters most for teams weighing Chainguard's stack: Safeguard doesn't require standardizing on one company's images or one company's signing infrastructure to get verifiable, audit-ready answers about what's in production and where it came from.