Chainguard Images and Wolfi vs Safeguard Gold: A New Minimal Base Image, or Fixes for the Images You Already Run

Chainguard and Safeguard both talk about rebuilding open source from source, and both end up in the same place for a buyer: a registry you pull from instead of a public one. The difference is what you pull. As of 28 Oct 2026, Chainguard Containers (still called Chainguard Images by much of the market) are minimal, mostly distroless images built on Chainguard's own Linux "undistro", Wolfi, so adopting them means changing your base image. Safeguard's side, in its canonical form: Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. The image you already run keeps its name and its distribution, and its vulnerable components are replaced by fixed builds. One approach removes things and changes the foundation. The other keeps the foundation and fixes what sits on it. This guide compares them fairly, says where Chainguard is clearly stronger, and ends with a bake-off plan you can run on your own services.

Chainguard facts below come from Chainguard's own documentation, pricing page, product pages and CVE policy, plus its public Wolfi repository, each linked and accessed on 28 Oct 2026. Safeguard facts come from Safeguard's registry page, documentation, CLI page, pricing page and launch post. Where a vendor page is silent or contradicts itself, the post says so instead of guessing. If you want the language libraries side of the story (Chainguard Libraries against Safeguard Gold for Java, Python and JavaScript), read the sibling guide, Chainguard Libraries vs Safeguard Gold and Package Firewall.

Key takeaways

• Chainguard changes your base image. Safeguard Gold fixes the one you chose. Chainguard's docs describe most images as distroless, with no shell or package manager, built on Wolfi and glibc. Safeguard's registry page describes Gold builds of images and packages you already pull, reachable by the same Docker Hub or registry path through registry.safeguard.sh.
• Chainguard has the larger, more mature container catalog. Its pages cite 3,000+ images on the product page and "over 2,000" in the docs, with FIPS variants, STIG hardening, Custom Assembly, an EOL grace period and a contractual CVE SLA on paid plans. Safeguard's registry page lists no coverage counts, so ask for a list against your own image inventory.
• "Zero CVE" has a definition, and it is narrower than it sounds. Chainguard's own FAQ defines it as no known CVEs at publish time. Its CVE policy ties the SLA clock to a qualifying patch being public, and describes the commitment as commercially reasonable efforts.
• Wolfi is open, with a one way door in the middle. The public Wolfi repository is a read-only clone synced from Chainguard's internal repositories, and outside pull requests cannot be merged directly. Chainguard decides what is in Wolfi.

First, a note on names

Chainguard's documentation now calls its image product Chainguard Containers, and its pricing page lists Containers, Libraries, VMs and Actions as separate products. Much of the market still says Chainguard Images, so this post uses both words for the same thing: Chainguard's catalog of hardened container images, served from cgr.dev. Chainguard OS is the name its docs give to the distribution under those images, alongside the open source Wolfi project. Chainguard Libraries (rebuilt Java, Python and JavaScript dependencies) is a different product with a different comparison, covered in the sibling guide.

What Chainguard Containers are (as of 28 Oct 2026)

The design: distroless, minimal, rebuilt constantly

Chainguard's overview page describes a collection of container images "designed for enhanced security through minimalism and supply chain integrity". Many images follow a distroless approach, containing the application and its runtime dependencies but no shell, no package manager and few utilities (Chainguard Containers overview, accessed 28 Oct 2026). Most images have a development variant, tagged with a -dev suffix such as latest-dev, that does include a shell and package manager. Chainguard recommends a multi stage build where the dev image builds your artifact and a standard image runs it. Some popular images also have a -full variant, which is designed to map to the upstream Debian based image, including packages, environment variables and entrypoint scripts, to ease migration (migration overview).

The overview lists the guarantees every image carries: automated nightly builds, build time SBOMs, Sigstore signatures, and reproducible builds with Cosign and apko. Chainguard says its images are rebuilt nightly, and that "our engineering team sometimes fixes vulnerabilities before they're detected." The containers product page adds claims of "97.6% fewer CVEs than OSS equivalents" and "~80% lower CVE accumulation over time." These are vendor figures without a stated method on the page, so treat them as a reason to run your own scan comparison, which this guide describes later.

What "zero CVE" means in Chainguard's own words

The containers page defines it plainly: "'Zero-CVE' means that there are no known CVEs at publish time." That is a fair and useful definition, and it is worth reading the rest of the policy around it.

Chainguard's CVE policy, last updated 28 April 2026, sets these timelines for Chainguard Containers, using "commercially reasonable efforts" (CVE policy, accessed 28 Oct 2026):

• CISA KEV listed vulnerabilities: 1 calendar day from when the CVE is listed and a qualifying patch is public.
• Critical: 7 calendar days from when a qualifying patch is public.
• High, medium and low: 14 calendar days from when a qualifying patch is public.
• New upstream versions: the latest public version built within 14 days of release, whether or not it fixes a known CVE.

The policy defines a qualifying patch as one where Chainguard's scanners identify the CVE, the CVE is fixable within the asset, and either a verified upstream fix exists or the asset can be rebuilt with updated compilers or libraries. It covers the latest version of a supported version stream. It excludes end of life streams (a separate EOL grace period of up to 180 days applies when purchased, per the policy), excludes backporting or cherry picking individual commits to third party software, and says that Custom Assembly images may fall outside the commitments. It also says that failing to fix a CVE because the fix would void a FIPS validation is not a breach. The policy treats Chainguard Libraries separately, with efforts based commitments and no stated timelines.

A 1 day KEV target is a strong commitment, and the fine print is ordinary for a vendor SLA. It does mean "Chainguard images have zero CVEs" should be read as no known CVEs in the latest supported stream at publish time, with a contractual patch clock that starts when a fix is available.

Chainguard's FAQ is candid about a related limit. A few images, it names Druid and Spark, carry notable numbers of CVEs marked pending upstream fix, because some fixes need breaking major upgrades, many sit in shaded JARs that bundle their dependencies, and a small portion have no fix (containers FAQ). The FAQ also says that when the owner has not released a patch, Chainguard "may apply a patch before it lands upstream", which is real and case by case.

Catalog, tags and plans

Chainguard's pages give different catalog sizes: 3,000+ images on the containers page, "over 2,000" in the docs, 1,800+ in the pricing FAQ, and "more than a thousand" in the catalog pricing doc. Counting rules differ (images versus tags, free versus production), so ask each vendor for a list matched against your own inventory.

Chainguard's published plan structure, from the pricing page and the docs (pricing, accessed 28 Oct 2026):

• Free images: free with a business email, with a small set of images (the pricing page says five to test and deploy in production). The docs say free images are limited to the latest build, tagged latest and latest-dev, and are not covered by the CVE remediation SLA.
• Catalog Starter: a free plan, described in the docs as in beta, that lets a team pick up to five non FIPS images from the broader catalog to pilot.
• Per Image: priced on request, licensed by the number and type of images (base, application, AI and ML, FIPS), with a contractual CVE SLA and all upstream supported tags.
• Catalog: the pricing page says "Starts at $19K for a team of 10", with enterprise pricing on request, licensed by engineering organization size, with full catalog access, a contractual CVE SLA and the ability to request new images.

Production plans add major and minor version tags (the free tier is latest only), unique time stamped tags, FIPS readiness and the SLA. The catalog pricing doc notes an organization limit of 2,500 image repositories. Read the live page on the day you buy.

FIPS, STIG, Custom Assembly and EOL

Several features matter for regulated buyers, and Chainguard is deep here:

• FIPS and STIG. The containers page carries a "FIPS 140-3 validated" badge, says "over 1,200 FIPS-validated container variants" exist, and adds OS level STIG hardening. These are Chainguard's own claims. If a validated cryptographic module is a hard contract requirement, put Chainguard in the evaluation.
• Custom Assembly. Production customers can add packages, certificates, environment variables and users to a Chainguard image through the console, chainctl, GitOps or API, and Chainguard builds and maintains the result, normally in under 20 minutes. You can add but not remove base packages (Custom Assembly).
• EOL grace period. Up to six months of rebuilds after a primary package reaches end of life, with eligibility rules and no exceptions to the six month limit. It does not cover backporting patches to the EOL package itself (EOL grace period). The CVE policy describes the grace period as purchasable, and the docs say it is offered to all Containers customers, so ask which applies to your order.
• Migration tooling. chainctl images discover reports the Chainguard replacement for each image reference in a repository, and the open source dfc converter ports Dockerfiles that use apk, apt or yum (dfc docs, images discover). The docs also describe Guardener, an AI agent for Dockerfile migration.

The shared responsibility model

Chainguard publishes a shared responsibility model that is worth reading before you sign. Upstream projects are responsible for releases and staying on supported dependencies. Chainguard is responsible for building every upstream supported version, assembling images from fully patched upstream software, and rebuilding with the latest toolchain where that is non breaking. Customers are responsible for staying on a supported version of the software, for building on fully patched Chainguard images, and for patching any components they add (shared responsibility model). For application images, the model draws the line at the language library layer: if updating a dependency is breaking, CVE management falls to the upstream project, and if it succeeds, to Chainguard. That division is reasonable, and it explains why a hardened base image does not remove the need to manage your own dependencies.

Wolfi: what it is, and what "open" means here

Wolfi is the Linux distribution under Chainguard Containers. Chainguard's overview describes it as a "community Linux undistro" for the container and cloud native era: a stripped down distribution that ships no kernel of its own and relies on the host or container runtime for one (Wolfi overview, accessed 28 Oct 2026). The properties that matter for a buyer:

• glibc, not musl. The page says Wolfi is designed to support glibc, and Chainguard's migration docs say its images are glibc based and that its packages cannot be mixed with Alpine packages, which are musl based. For Python wheels with C extensions, Java native libraries and Go with CGO, glibc is the compatible choice, and for teams coming from Alpine it is a real change to test.
• apk format. Wolfi uses the apk package format that Alpine popularized, but the GitHub README warns that the packages are not compatible with each other.
• Build tooling. The distribution is built with melange and images with apko, both open source Chainguard tools. Every package ships a build time SBOM, and the build system is described as declarative and reproducible.
• Rolling releases. Wolfi uses the latest releases of packages by default, and the overview says rolling releases "target an unmatched CVE SLA". The page gives no schedule or figures.
• Repositories. Chainguard's package model docs describe two public repositories, Wolfi and Extra (which carries utilities under less permissive licenses where redistribution is allowed), plus a private APK repository for each customer. Free images use apk.cgr.dev/chainguard, and the docs note that these public repositories typically hold the latest stable versions and exclude FIPS validated packages (package repositories).

Who controls Wolfi

Two facts from Chainguard's own repository are important to a procurement or architecture review. The wolfi-dev/os repository describes itself as "a read-only public clone, synced from internal Chainguard repositories", and states that "pull requests opened here cannot be merged directly". The contributing guide says a Chainguard engineer reviews proposed changes on a best effort basis with no guaranteed timeline, that accepted changes are applied internally first and then synced back, and that Chainguard decides which packages exist in Wolfi under its inclusion and retention policy (Wolfi repository, contributing guide).

That is not a criticism, since a vendor that carries the SLA needs to control its build. It does mean Wolfi is open in licence and visibility and governed in practice by one company. If your risk register asks what happens to the distribution under your base images if the vendor relationship ends, plan for it: Wolfi packages are public, but the commercial images, private repositories and build factory are Chainguard's. Chainguard's Wolfi overview says the Chainguard Containers built on Wolfi are open source and free of charge, and its docs limit the free tier to latest tags.

For deeper background on the distro, see our earlier explainers, Wolfi, the community Linux undistro and Wolfi Linux: a buyer's rationale.

What Safeguard Gold is for containers

The model: fix what you run, serve it from a registry

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization.

The registry page describes the mechanics (registry.safeguard.sh, accessed 28 Oct 2026). Gold serves open source packages and container images that Safeguard "has fixed, rebuilt, scanned and signed", and anything not in Gold passes through unchanged from the public source. The registry keeps a verified cache of passed through content and logs every download for audit. Container images are served through the same endpoint: you log in with docker login registry.safeguard.sh, Docker Hub images keep their Docker Hub path (the page's example is library/python:3.12), and images from other registries put the registry host first. Images can be pinned by digest.

That last point is the heart of the comparison. For a service that today does FROM python:3.12, adopting Gold means pointing the pull at the registry. It does not mean choosing a new distribution, rewriting apt-get lines to apk add, learning a different entrypoint convention or debugging without a shell. Your image is still the image you chose. The vulnerable components inside it are replaced by fixed builds where Gold has them, and everything else passes through unchanged.

How a fix gets built

Safeguard's launch post, published 15 Oct 2026, describes the method (introducing Gold sourcing): find the upstream commit that fixed a vulnerability, backport it to the version you run, rebuild, and run the tests. Its pre launch examples were a minimist@1.2.5-sg.1 build for CVE-2021-44906 with 163 of 163 tests passing, and a pyyaml==5.3+sg.1 build for two critical CVEs with 1,286 tests passing. The post also describes a lodash@4.17.21 attempt that was refused, with nothing published, because the evidence was not there, and calls a refusal "the correct result". That is the behaviour you want from a fix pipeline, and it is a reason to read the VEX statement on each build rather than trust a badge.

The registry page describes tiers. Gold keeps the latest version of each package line clean, and older versions are clean as of their build date. Gold Live keeps every version clean, with continuous rescans, rebuilds and backports to older lines, faster fix targets, and requests for components not yet in Gold. The page publishes fix targets, which it does not frame as guarantees: for Gold, critical in 7 days, high in 14 and medium or low in 30, with notification of a new issue in 24 hours; for Gold Live, critical in 72 hours, high in 7 days and medium or low in 14.

Verification

Gold builds are signed with a Safeguard key held in a hardware backed vault, published for verification at the registry's key endpoint (cosign.pub, ECDSA P-256), according to the registry page. For images, you verify the signature and SLSA provenance with cosign verify and cosign verify-attestation, using --insecure-ignore-tlog and the digest reference. For packages, the SBOM, provenance and VEX are available from attestation endpoints under the registry's _gold/attest path. Compare that with Chainguard, whose docs describe Sigstore signatures and cosign retrieval of signed attestations such as the SPDX SBOM. The trust models differ: a published vendor key versus Sigstore tooling. Your security team should decide which fits your verification policy.

The rest of the Safeguard container story

Gold is the registry. Around it:

• Scanning and SBOMs. The CLI scans an image by reference with safeguard scan --image REF, and safeguard patch-image rebuilds an image with patched layers applied (cli.safeguard.sh, accessed 28 Oct 2026).
• Self healing containers. The docs describe a loop of detect, plan, rebuild and promote: Griffin, Safeguard's security model, plans the patch, the runner rebuilds the image and runs your tests, and a passing image is pushed to your registry under a new tag, with modes from advisory pull requests to approval gated promotion. For distroless and scratch images, the page says Safeguard rebuilds only the layer for the affected binary (self healing containers, accessed 28 Oct 2026).
• Pull requests. Griffin opens tested, policy gated pull requests that move dependencies to safe versions (AI Remediate docs).
• Gold Open Source. gold.safeguard.sh is the free, no login lookup for packages, container images and CVEs, with a recommended safe version.

The registry page publishes no coverage counts and does not list which images exist as Gold builds today. That is the first question to ask Safeguard, and the checklist turns it into a test.

Side by side

How the approaches differ

Smaller image, or fixed image

A distroless image has fewer things a scanner can report and fewer things an attacker can use after a foothold: no shell, no package manager, no curl. Chainguard's container variants doc makes this argument directly, and it is sound. The cost is that the application must run in that environment, and some stacks need a development image to build and a standard image to run.

Gold takes the opposite trade. It does not remove software. It replaces vulnerable builds of software with fixed ones. That suits a specific set of CVEs in components you must keep, and it asks nothing of your runtime. It does not shrink the image, and the registry page does not claim to. If auditors care about attack surface and your applications can live without a shell, minimal wins that point. If the image cannot change shape this quarter, fixed wins.

The timing question

The two vendors express timing differently. Chainguard's SLA is contractual on paid plans, with a clock that starts when a qualifying patch is public. Safeguard's targets are published on the registry page, which does not frame them as guarantees, for the latest version of a package line on the Gold tier. For a buyer who needs a contract clause, Chainguard's paperwork is more mature today. For the gap before any patch exists, the question is what each vendor does when upstream has no fix: Chainguard says it may patch ahead of upstream case by case, and Safeguard's Gold Live tier describes backports to older lines and requests for components not yet in Gold. Ask each for the last ten critical CVEs and its actual time to a published fix.

What you can verify yourself

With Chainguard you pull a signed SBOM attestation with cosign (cosign download attestation with the SPDX predicate type against a cgr.dev image, per its docs) and check Sigstore signatures. With Gold you verify the signature against the published key and read the SBOM, provenance and VEX at the attestation endpoints. The trust anchors differ, and the test is the same: an engineer who has not spoken to either vendor runs the verification commands on a sample image and records how long it took.

Where each approach stops

Chainguard says plainly that it is not responsible for CVEs in software you add on top of its base images. Gold fixes the components it has built, and your first party code and unlisted dependencies sit outside it. The rest of your supply chain needs its own controls: dependency scanning, reachability, policy gates and fix pull requests. Our earlier posts cover the wider view, on Chainguard versus Docker official images, Chainguard alternatives for hardened container images and Chainguard pricing and total cost of ownership.

An illustrative walk-through

This is a hypothetical scenario, not a customer result. Imagine a Python API service built FROM python:3.12 on Kubernetes, with a Debian based runtime, a native image processing library, and a scanner reporting a few dozen findings in the base image, most in packages the service never calls.

Path A: Chainguard. Run chainctl images discover to see the replacement image and whether your organization can pull it. Convert the Dockerfile with dfc, split the build into a development stage and a standard runtime stage, swap any useradd calls for the BusyBox forms, confirm the entrypoint, and check the native library on glibc. Debugging a pod now means an ephemeral debug container, since the runtime image has no shell. The result is a much smaller image and a much shorter scan report, and the work is a migration project per service, which the docs recommend rolling out gradually, starting with non critical applications.

# Before
FROM python:3.12
RUN apt-get update && apt-get install -y libjpeg-dev
COPY . /app
RUN pip install -r /app/requirements.txt
CMD ["python", "/app/main.py"]

# After, in the shape the Chainguard docs describe (a sketch, not a tested file)
FROM cgr.dev/ORG/python:latest-dev AS build
COPY . /app
RUN pip install --target /app/deps -r /app/requirements.txt
FROM cgr.dev/ORG/python:latest
COPY --from=build /app /app
ENTRYPOINT ["python", "/app/main.py"]

Path B: Safeguard Gold. Create a pull token, log in to the registry and point the pull at it. The Dockerfile keeps the same image and tag, the FROM line changes only by the registry host, and the build pins by digest. Where Gold has a fixed build of an affected component, the build gets it with an SBOM, provenance and VEX you can read. Where it does not, the request passes through unchanged and you can ask for a Gold request. The image keeps its shape, so the scan report shrinks only by what Gold fixed. The work is configuration and verification rather than porting.

# Path B, a sketch: log in, pull through the registry, verify against the digest
echo "$SAFEGUARD_TOKEN" | docker login registry.safeguard.sh -u token --password-stdin
docker pull registry.safeguard.sh/library/python:3.12
cosign verify --key cosign.pub --insecure-ignore-tlog registry.safeguard.sh/library/python@sha256:DIGEST

Neither path is complete alone. Path A leaves your Python dependencies to another tool, and Path B leaves the shell and package manager in the runtime image. Many teams will do A for services that can take the migration and B for the long tail of images they cannot change quickly.

When to choose Chainguard

Choose Chainguard Containers when:

• Attack surface reduction is the goal. Distroless images with no shell or package manager are a recognized control, and Chainguard's catalog is a well developed source of them.
• You need FIPS validated variants or STIG hardened images, and Chainguard's catalog already has them as a product line.
• You want a contractual CVE SLA with defined timelines, including a 1 day target for KEV listed vulnerabilities, written into an order.
• You can afford the migration, and your applications are suited to minimal runtime images: Go, Java, Node and Python services with clear build and run stages.
• You want a single vendor for base images and a customized image build, through Custom Assembly, with Chainguard rebuilding and maintaining the result.

When to choose Safeguard

Choose Safeguard Gold when:

• The images are the images. You have many services, vendor supplied or legacy bases, or standard golden images that cannot change distribution this year, and you need the known CVEs in them fixed.
• You want the fix and the evidence in one step. Each Gold build carries an SBOM, provenance and VEX, and the registry logs every download for audit.
• You also need packages, not only images. The same registry serves npm, PyPI, Maven, Go, NuGet, Composer, RubyGems, Cargo, Helm and OS packages (apt, dnf, apk), per the registry page, so one token and one policy cover the build.

Using both

The two are not in competition on every service. Move the services that can take it onto Chainguard minimal images, keep the rest on their current bases but pull them through Gold, and run Safeguard scanning and policy gates over all of it. Safeguard's scanner takes an image reference, so a Chainguard image can be scanned and gated like any other (confirm on your own images). Decide which system is the source of truth for each image's SBOM and VEX statement, so downstream consumers get one answer.

Evaluation checklist: a container bake-off

Run this on five to ten real services across languages, including one stateful or vendor supplied image. Record numbers before you read the vendors' answers.

1. Inventory. List every base and runtime image with tags. Run chainctl images discover for the Chainguard match, and ask Safeguard which of the same images and packages exist as Gold builds today. Record the match rate.
2. Baseline scan. Scan current images with the scanner your security team trusts. Save raw output and SBOMs, split by base layer and your layers. Agree beforehand whether VEX statements and vendor advisories count.
3. Migration cost. For Chainguard, time the Dockerfile port, user and entrypoint changes, build and run stages, tests and the no shell debug workflow. For Gold, time the registry login, pull path change, digest pinning and verification.
4. Verify the evidence. Have an engineer who has not talked to either vendor verify signatures, retrieve the SBOM and read the provenance using each vendor's published commands. Record minutes and blockers.
5. Tags. Check which tags each plan gives you. The Chainguard free tier is latest only, and production plans add major and minor tags. For Gold, check which tier covers older versions.
6. Time to fix. Take the last ten critical or KEV listed CVEs that hit your images. Ask each vendor for the date its fix reached the registry, and compare with your detection dates.
7. No upstream fix. Pick one CVE with no upstream fix. Ask what each vendor does, how long it takes and how the fix shows in the SBOM and VEX.
8. End of life. List images past upstream end of life. Ask Chainguard how the grace period applies and whether it is purchased. Ask Safeguard which older lines Gold Live covers.
9. FIPS and STIG. If required, ask each vendor for the exact validated variants and certificates, and how a fix interacts with the validation.
10. Compatibility. Run the full test suite, including load and failure tests, on each candidate. Watch native libraries, locale and timezone data, certificates and anything that shells out.
11. Customization. If you need internal CA certificates or extra packages, test Custom Assembly on Chainguard and your own Dockerfile layer on Gold, and record the maintenance path.
12. Application layer. Scan again with application dependencies included. Count what remains and who owns it. Decide which tool fixes it.
13. Registry in the path. Test pulls through your normal registry or mirror, with caching, rate limits and outage behaviour. Chainguard documents pull through guides for Artifactory and Amazon ECR. For Gold, test the cache and passthrough behaviour the registry page describes.
14. Air gap and residency. If you need offline or in VPC operation, ask both vendors for the delivery mechanism and refresh cadence.
15. Commercials. Get written quotes for the same scope. Chainguard's Catalog plan starts at $19K for a team of 10 per its pricing page. For Safeguard, see safeguard.sh/pricing for current plans and confirm in a quote. Include migration labour.
16. Exit plan. With Chainguard, leaving means re porting to another base. With Gold, it means pointing the pull back at the public registry. Record the answer in the decision record.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

Is Chainguard Images the same as Chainguard Containers?

Yes. Chainguard's documentation now calls the product Chainguard Containers, and the market still says Chainguard Images. Both mean Chainguard's catalog of hardened container images served from cgr.dev.

What is Wolfi, and is it the same as Chainguard OS?

Wolfi is a community Linux "undistro" started by Chainguard, built for containers, using glibc and the apk package format, with no kernel of its own. Chainguard's docs say its container images are built with packages from both Wolfi and Chainguard OS. The public Wolfi repository is a read-only clone synced from Chainguard's internal repositories. Source: Chainguard's Wolfi overview, package model docs and the wolfi-dev/os repository, accessed 28 Oct 2026.

Does Safeguard Gold make my existing base image minimal?

No. Gold serves fixed, rebuilt builds of the open source packages and images you already pull, with the same upstream names, and passes through anything it does not have. The registry page does not describe removing shells or package managers from an image. If a smaller attack surface is your goal, a minimal base such as Chainguard's is the right tool, and you can use Safeguard to scan and gate it. Source: registry.safeguard.sh, accessed 28 Oct 2026.

How does Safeguard Gold build a fix?

According to Safeguard's launch post, the method is to find the upstream commit that fixed the vulnerability, backport it to the version you run, rebuild, and run the tests. Each build is scanned and signed before publication, and the post describes refusing to publish a fix when the evidence is not there. Source: introducing Gold sourcing, 15 Oct 2026.

What does each vendor cost?

Chainguard's pricing page, accessed 28 Oct 2026, lists free images, a Catalog plan that "starts at $19K for a team of 10" and per image and Libraries pricing by quote. For Safeguard, see safeguard.sh/pricing for current plans and confirm in a quote.

Can I use Chainguard images and Safeguard together?

Yes. You can run Chainguard minimal images for services that can take the migration, use Gold for images you cannot change, and scan, attest and gate all of them with Safeguard. Agree one source of truth for each image's SBOM and VEX statement.

Which is better for regulated environments that require FIPS?

If you need FIPS validated cryptography in the image, Chainguard's catalog is the one that publishes validated variants today, with Chainguard citing over 1,200 FIPS validated container variants and FIPS 140-3 validation. Safeguard's registry page does not list FIPS validated image variants, so ask Safeguard what it can provide and document the answer. Source: Chainguard containers page, accessed 28 Oct 2026.

Sources and access dates

All pages were accessed on 28 Oct 2026. Vendor facts change, so verify anything you plan to rely on.

• Chainguard: pricing, containers, CVE policy, Containers overview, Containers FAQ, migration overview, container variants, shared responsibility model, EOL grace period, Custom Assembly, package repositories, Catalog Starter, catalog pricing, what Chainguard will build, retrieve SBOMs, Dockerfile Converter, images discover.
• Wolfi: Wolfi overview, wolfi-dev/os, contributing guide.
• Safeguard: Gold Registry, introducing Gold sourcing, 15 Oct 2026, Gold Open Source, CLI, self healing containers docs, AI Remediate docs, pricing.

Chainguard and Wolfi are named here in plain text for comparison. This post does not imply any partnership with or endorsement by Chainguard, and Chainguard has not reviewed it.