Wolfi OS: The Linux Distribution Built for Secure Containers

Every container image sits on top of a Linux distribution. That distribution determines your baseline vulnerability count, your package update cadence, and ultimately, how much time your team spends triaging scanner output instead of building features.

Traditional distributions—Debian, Ubuntu, Alpine—were designed for general-purpose computing. They carry legacy packages, slow security patch cycles, and packaging decisions made decades ago for server and desktop use cases. Wolfi was built from scratch for one purpose: producing secure container base images.

What Makes Wolfi Different

Designed for Containers, Nothing Else

Wolfi has no kernel. No init system. No bootloader. It cannot run on bare metal or as a VM operating system. It provides a userspace package set optimized for container runtimes.

This constraint is the feature. Every design decision is made in the context of "does this make containers more secure and smaller?" If the answer is no, it does not go in.

glibc, Not musl

Alpine's biggest limitation for production workloads is musl libc. While musl is small and clean, it causes real compatibility problems:

• Go binaries with CGO enabled may crash or behave differently
• Python C extensions sometimes fail to build or produce incorrect results
• Java Native Interface (JNI) calls can behave unexpectedly
• DNS resolution differences (musl's stub resolver vs glibc's full resolver)
• Thread handling differences that surface under load

Wolfi uses glibc. Applications built for mainstream Linux distributions work without modification. You get the minimalism benefits of Alpine without the musl compatibility tax.

Rolling Release with Rapid Patching

Wolfi does not have fixed release cycles. When a CVE is patched upstream, Wolfi rebuilds the package from source and publishes it. The typical turnaround from upstream fix to Wolfi package update is measured in hours.

Compare this to traditional distributions:

| Distribution | Typical CVE Patch Lag | |---|---| | Debian Stable | Days to weeks | | Ubuntu LTS | Days to weeks | | Alpine | Days | | Wolfi | Hours |

This matters because the window between CVE disclosure and patched package is the window where your containers are vulnerable and everyone knows it.

Every Package Has an SBOM

Every Wolfi package is built with a corresponding SBOM in SPDX format. This is not a post-hoc scan—it is generated during the build process and reflects exactly what went into the package.

# Wolfi packages include SBOM metadata
apk info --provides wolfi-base
# Shows exact components and versions

When you build a container on Wolfi, the SBOM is a byproduct of the package installation, not a separate scanning step that might miss something.

Signed Everything

Every Wolfi package and image is signed using sigstore:

• Package signatures verify the publisher identity
• Build provenance attestations verify the build pipeline
• Image signatures verify the image has not been tampered with

# Verify a Wolfi-based image
cosign verify \
  --certificate-identity-regexp '.*chainguard.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  cgr.dev/chainguard/wolfi-base:latest

Building with Wolfi

Using Wolfi Base Images

FROM cgr.dev/chainguard/wolfi-base:latest

# Install packages with apk
RUN apk add --no-cache python-3.12 py3-pip

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app/ /app/
CMD ["python", "/app/main.py"]

Using melange for Custom Packages

Wolfi uses melange for package building. If your application needs a package not in the Wolfi repository, you can build your own:

# melange.yaml
package:
  name: myapp
  version: 1.0.0
  epoch: 0
  description: My application
  copyright:
    - license: Apache-2.0

environment:
  contents:
    repositories:
      - https://packages.wolfi.dev/os
    keyring:
      - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
    packages:
      - build-base
      - go

pipeline:
  - uses: go/build
    with:
      modroot: .
      packages: ./cmd/server
      output: myapp

melange build melange.yaml --signing-key melange.rsa

The resulting .apk package includes an SBOM and can be signed with your organization's key.

Using apko for Image Assembly

apko builds OCI images directly from APK packages without a Dockerfile:

# apko.yaml
contents:
  repositories:
    - https://packages.wolfi.dev/os
  keyring:
    - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
  packages:
    - wolfi-base
    - python-3.12
    - py3-pip

accounts:
  groups:
    - groupname: app
      gid: 1000
  users:
    - username: app
      uid: 1000
      gid: 1000
  run-as: 1000

entrypoint:
  command: /usr/bin/python3

archs:
  - x86_64
  - aarch64

apko build apko.yaml myapp:latest myapp.tar

This produces a minimal OCI image with exactly the packages specified, multi-architecture support, and an embedded SBOM. No Dockerfile layers, no shell history, no build artifacts.

Wolfi in the Supply Chain

Provenance Chain

With Wolfi, every step of the supply chain is verifiable:

1. Source code: Fetched from upstream with hash verification
2. Build process: Reproducible builds with melange, logged and attested
3. Package: Signed APK with embedded SBOM
4. Image: Assembled with apko, signed with cosign, provenance attested

This creates an unbroken chain from upstream source to running container. Supply chain attacks that modify packages in transit are detectable because every link in the chain is cryptographically verified.

VEX (Vulnerability Exploitability eXchange)

Wolfi publishes VEX documents for known CVEs that do not affect its packages. If a CVE exists in a library but Wolfi's build configuration makes it unexploitable, the VEX document records that determination.

This reduces false positives in vulnerability scanners. Instead of seeing 50 CVEs and manually triaging each one, VEX-aware scanners (Trivy, Grype) automatically filter out CVEs that the package maintainer has confirmed are not exploitable in this context.

Wolfi vs Alpine: A Direct Comparison

Teams choosing between Wolfi and Alpine should consider:

Package Freshness

# Check OpenSSL version in Alpine
docker run --rm alpine:3.19 apk info openssl
# openssl-3.1.4-r2

# Check OpenSSL version in Wolfi
docker run --rm cgr.dev/chainguard/wolfi-base:latest apk info openssl
# openssl-3.2.1-r0  (typically newer)

Wolfi consistently ships newer versions because it builds from current upstream sources.

Compatibility

Applications that fail on Alpine due to musl typically work on Wolfi without modification. If you have been maintaining Alpine-specific patches or workarounds, Wolfi eliminates that maintenance burden.

Ecosystem Maturity

Alpine has a decade-long track record with a massive community. Wolfi is newer with a smaller but growing ecosystem. For common packages, Wolfi coverage is excellent. For niche packages, you may need to build your own with melange.

Adopting Wolfi Incrementally

1. Start with new services. Do not migrate everything at once. Use Wolfi for new microservices and compare the experience.

2. Replace Alpine images. If you are on Alpine, Wolfi is the easiest migration because both use apk. Dockerfiles need minimal changes.

3. Replace Debian/Ubuntu images. This requires changing package installation commands from apt-get to apk and verifying package name mappings.

4. Build custom packages. For internal libraries or applications, create melange build configurations to produce signed APK packages.

5. Adopt apko for image assembly. Move from Dockerfiles to apko YAML configurations for maximum reproducibility and minimal image size.

How Safeguard.sh Helps

Safeguard.sh integrates with Wolfi's SBOM and VEX ecosystem to provide accurate vulnerability assessments that account for Wolfi's build-time security decisions. The platform tracks your migration from traditional base images to Wolfi, monitors the Wolfi package repository for new security updates, and verifies that your images are using the latest patched packages. For organizations running mixed base images, Safeguard.sh provides comparative dashboards showing vulnerability exposure across Wolfi, Alpine, Debian, and Ubuntu bases, making the business case for migration visible to decision-makers.