Container Security

Now pick what to compare Google Distroless against.

Google Distroless clear

Open a name for its full profile

Chainguard Containers
Scored
Chainguard · Freemium · 3 capabilities in this domain · 4.04 / 5
Compare →
Docker Hardened Images
Scored
Docker · Freemium · 3 capabilities in this domain · 4.00 / 5
Compare →
Chainguard VMs
Capabilities only
Chainguard · Commercial · 3 capabilities in this domain
Compare →
Docker Scout
Capabilities only
Docker · Freemium · 3 capabilities in this domain
Compare →
Echo Container Images
Capabilities only
Echo · Commercial · 3 capabilities in this domain
Compare →
RapidFort
Capabilities only
RapidFort · Freemium · 3 capabilities in this domain
Compare →
Snyk Container
Capabilities only
Snyk · Freemium · 3 capabilities in this domain
Compare →
The Guardener
Capabilities only
Chainguard · Commercial · 3 capabilities in this domain
Compare →
Bitnami Secure Images
Capabilities only
Bitnami · Commercial · 2 capabilities in this domain
Compare →
Chainguard OS Packages
Capabilities only
Chainguard · Commercial · 2 capabilities in this domain
Compare →
Iron Bank
Capabilities only
Platform One (U.S. Department of Defense) · Free · 2 capabilities in this domain
Compare →
Minimus
Capabilities only
Minimus · Commercial · 2 capabilities in this domain
Compare →
Clair
Capabilities only
Red Hat · Open Source · 1 capabilities in this domain
Compare →
Copacetic
Capabilities only
Cloud Native Computing Foundation (CNCF) · Open Source · 1 capabilities in this domain
Compare →
Docker Bench for Security
Capabilities only
Docker · Open Source · 1 capabilities in this domain
Compare →
Dockle
Capabilities only
Goodwith Tech · Open Source · 1 capabilities in this domain
Compare →
Google Distroless
Capabilities only
Google · Open Source · 1 capabilities in this domain
selected
Grype
Capabilities only
Anchore · Open Source · 1 capabilities in this domain
Compare →
Hadolint
Capabilities only
Hadolint Project · Open Source · 1 capabilities in this domain
Compare →
Microsoft Defender for Containers
Capabilities only
Microsoft · Commercial · 1 capabilities in this domain
Compare →

In Container Security

The Guardener

Chainguard · Container Security

Close ×

CommercialCompany

The Guardener converts a legacy container build to a hardened Chainguard base without a human rewriting it. It parses the existing Dockerfile and its build context, maps the Debian, Ubuntu or Alpine packages it installs to Chainguard equivalents, restructures the build into a multi-stage form that keeps compilers and package managers in the build stage only, then iterates layer by layer until the migrated image behaves like the original. It emits a ready-to-run Dockerfile alongside a migration report showing the change in image size, CVE count and filesystem composition.

Website ↗

What it does4 capabilities · 2 at full coverage

2 of 4 at full coverage.

Base Image CVE Remediation AutomationPartialCONTAINER · level 3 · 12 providers
Dockerfile & Image Configuration LintingFullCONTAINER · level 2 · 4 providers
Minimal Hardened Base ImagesFullCONTAINER · level 3 · 14 providers
Automated Remediation Pull RequestsPartialDEVSEC · level 2 · 12 providers

What it proves17 controls across 10 frameworks

Satisfied through its capabilities, not claimed by the vendor.

CRA3 / 41Annex I Part I (2)(b) Annex I Part I (2)(j) Annex I Part II (2)
DSOMM3 / 19BD-Patch-Management IM-Infrastructure-Hardening TV-Static-Depth-Infrastructure
SAMM 2.03 / 90O-EM-1-B O-EM-2-A O-EM-2-B
SSDF 1.12 / 42PW.9.1 RV.2.2
ASVS 5.01 / 17V13
CIS Benchmarks1 / 6CIS Docker Benchmark
CIS Controls1 / 18CIS 4
CNAS Top 101 / 10CNAS-1
CSF 2.01 / 106PR.PS-02
S2C2F1 / 25UPD-2

What it stops3 techniques · 1 risk

3 techniques countered, 3 of them common

Command and Scripting InterpreterT1059Very Common
Exploitation of Known Vulnerable ComponentVery Common
Escape to HostT1611Common

1 risks reduced

Exploitable vulnerabilities in container base imagesHigh

Where it runs2 phases · 2 ways to deploy

Capabilities per lifecycle phase

Code2
Build3

How it is delivered

CI/CD integrationCLI tool

What it unlocks4 activities · reaches level 5

Program activities its capabilities support, reaching level 5. Supporting an activity is not completing it.

Level 2

Enforce Dockerfile and image standardsLow effort

Level 3

Practice test-driven security with security unit testsMedium effort
Standardize on minimal hardened base imagesMedium effort

Level 5

Near-zero known vulnerabilities in production imagesHigh effort

How it holds up4 strengths · 4 limitations · 3 uses it suits

Strengths

Removes the dominant cost of a hardened-image program
Produces a reviewable diff rather than an opaque rewrite
Surfaces packages with no equivalent early instead of mid-migration
Makes a large migration a batch job rather than a project plan

Limitations

Requires a Chainguard subscription to be worth running
Output still needs review and the service's own test suite
Cannot invent an equivalent for a package Chainguard does not build
Entry-point scripts that depend on a shell need human judgment

Best for

Container estates in the hundreds of images
Programs that stalled after a successful pilot
Teams with no spare platform capacity for hand migration

Proof points

Maps Debian, Ubuntu and Alpine packages to Chainguard equivalents automatically
Restructures single-stage builds into multi-stage builds so build tooling stays out of the runtime image
Iterates until the migrated image behaves like the original rather than stopping at a base-image swap
Produces a reviewable report, so the migration is a pull request rather than a leap of faith

How the analysis works

Build-context analysis and iterative rebuild-and-compare rather than static advice; the output is a working build, not a recommendation

How it works

The tool reads the Dockerfile, the build context and, where available, the built image, and builds a model of what the image actually contains and does. It resolves each installed OS package against the Chainguard and Wolfi catalog, selecting a development variant for build stages that genuinely need a shell, a compiler or a package manager and a production variant for the final stage. It then rebuilds, compares the resulting filesystem and runtime behavior against the original and repeats until the differences are either gone or explained. The output is a Dockerfile plus a report naming every package that moved, every package with no equivalent, and the resulting size and vulnerability delta.

Organization size it suits

Any organization with more container builds than engineers willing to hand-port them; the value scales with service count

What it costsPer image or catalog subscription

LicensingPer image or catalog subscription

Priced perimage or catalog per year

BillingSubscription

Scales withNumber of hardened images or catalog tier consumed

Total cost

Compare against engineering time spent triaging and patching base-image CVEs.

What it takes to run0.3 FTE at peak · 1 role · 4 evidence outputs

Peak staffing0.25 FTE

Roles it needs

Platform Engineer0.1–0.25 FTE

Evidence it produces

Migrated multi-stage Dockerfile ready for reviewMigration report with before-and-after image size and CVE countFilesystem composition diff between original and migrated imageList of packages with no Chainguard equivalent for exception handling

Compliance reporting

Evidence of systematic base-image remediation for vulnerability-management programsBefore-and-after CVE counts suitable for risk-acceptance and exception closure records

Deployment

Runs as a CLI against a repository, so it fits naturally as a scheduled job that opens migration pull requests in batches rather than as an interactive tool one engineer drives. Batching by base image rather than by team is usually faster, because services sharing a base image fail in the same way and can be fixed once.

Migrating to it

Treat its output as a pull request from a competent contributor, not as a finished answer. Review the packages it dropped, run the service's own integration tests against the migrated image, and pay attention to entry-point scripts: anything that assumed a shell in the final stage will have been moved or removed, and that is the change most likely to surface in staging rather than in the build.

What it works with2 standards

Standards and formats

OCI Image SpecificationSPDX (ISO/IEC 5962)

What else to look at1 alternative · 9 siblings

Open-source alternatives

RapidFortFreemium

Same family

Chainguard ActionsCommercial
Chainguard ContainersFreemium · 4.04
Chainguard FactoryCommercial
Chainguard LibrariesCommercial
Chainguard OS PackagesCommercial
Chainguard VMsCommercial
WolfiOpen Source
apkoOpen Source
melangeOpen Source

What backs this up

No measurement, incident or pipeline using it.

Gantry 7.1.0 · OFF.12 · OFF.13