Book 1:1 office hours to ask us anything about images or troubleshoot any issues.

Hands on with Chainguard for a live demo on how to switch to Chainguard Images!

Chainguard Images is a collection of container images designed for minimalism and security.

Many of these images are distroless; they contain only an application and its runtime dependencies. There is no shell or package manager.

All these images are built using apko and melange. Combined, these tools provide for a reproducible, declarative approach to building OCI images. We aim to build images from the latest sources every night, ensuring that vulnerabilities are addressed as quickly as possible.

melange lets you build apks using declarative YAML pipelines. apks are .apk packages compatible with the package manager used by Alpine, similar to .deb or .rpm for instance.

apko lets you bundle a collection of APKs into an OCI image using a declarative YAML manifest.

Chainguard Images provide SBOM support and signatures for known provenance and more secure base images. They can be part of an approach to a secure software factory.

All of the images are based on the Wolfi un-distro, with the exception of:

• cgr.dev/chainguard/static:latest
• cgr.dev/chainguard/busybox:latest
• cgr.dev/chainguard/git:latest

...which are based on Alpine Linux and musl.

The above Alpine-based images have an equivalent Wolfi-based image, tagged :latest-glibc.

All Wolfi-based images are based on glibc, with the exception of gcc-musl and musl-dynamic.

Our images are available via cgr.dev.

For example, to pull the apko image with Docker:

docker pull cgr.dev/chainguard/apko 

There are a wide variety of images available. For more information, refer to the authoritative list of images or documentation.

We'll cover some of the main categories and highlights below.

The static image is designed for running statically compiled binaries. Unlike the completely empty scratch image, we do include some commonly required files and directories such as:

• Root certificate data
• /etc/passwd and /tmp

The most common way to use this image is with a multistage Dockerfile. For example:

# syntax=docker/dockerfile:1.4
FROM cgr.dev/chainguard/gcc-glibc:latest as build

COPY <<EOF /hello.c
#include <stdio.h>
int main() { printf("Hello World!"); }
EOF
RUN cc -static /hello.c -o /hello

FROM cgr.dev/chainguard/static:latest

COPY --from=build /hello /hello
CMD ["/hello"]

We can compile and run this with:

$ DOCKER_BUILDKIT=1 docker build -t c-static .
...
$ docker run c-static
Hello World!

In some cases it is easier to produce binaries that are dynamically linked against glibc or musl, but otherwise self-contained. In those cases you can use the following images:

• glibc-dynamic

These images can be used to run applications:

• python
• node
• ruby
• java

These images can be used to compile artifacts for use in runtime or base images. For instance the go image can be used to compile golang code for use in the static base image.

We have plans to include extra tooling in these images for creating provenance information such as SBOMs.

Examples:

• go
• gcc-glibc
• gcc-musl
• jdk
• maven
• bazel

These images contain stand-alone software, such as databases and web servers, as well as tooling such as apko and melange.

Because our images are constantly rebuilt with the latest sources and include the absolute minimum of dependencies, they typically have significantly less vulnerabilities than equivalent images.

For example:

• nginx
• git
• kubectl
• apko
• melange

All Chainguard Images are signed using Sigstore, and you can check the signature using cosign. For our apko image for example, you can run the following:

cosign verify cgr.dev/chainguard/apko \
    --certificate-identity=https://github.com/chainguard-images/images/.github/workflows/release.yaml@refs/heads/main \
    --certificate-oidc-issuer=https://token.actions.githubusercontent.com | jq

Your output will indicate that the cosign claims were validated.

This verifies that the image was keylessly signed by the GitHub Actions release workflow from the main branch.

All Chainguard Images come with a Software Bill Of Materials (SBOM) generated at build-time. The SBOM can be downloaded using the cosign tool e.g:

$ cosign download attestation --predicate-type https://spdx.dev/Document --platform linux/amd64 cgr.dev/chainguard/nginx | jq -r .payload | base64 -d | jq
{
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "sbom-sha256:05f301c5da6b701a1024dce52ccb9c58a61f98cd9816432ace5c0f7bfef40df7",
  "spdxVersion": "SPDX-2.3",
  "creationInfo": {
    "created": "2022-09-22T01:41:52Z",
    "creators": [
      "Tool: apko (canary)",
      "Organization: Chainguard, Inc"
    ],
    "licenseListVersion": "3.16"
  },
  "dataLicense": "CC0-1.0",
  "documentNamespace": "https://spdx.org/spdxdocs/apko/",
  "documentDescribes": [
    "SPDXRef-Package-sha256-a8aa25c0811fec7afc8de07be49340e27c4bb752fde24a1dae0509d1a3824b3a"
  ],
  "packages": [
  ...

Make sure to specify the required platform, or the resultant SBOM may only cover the image manifest and not the contents of the image.

For more information on Chainguard images and how to use them visit Chainguard Academy.

You can learn more about Wolfi, distroless images, apko, and melange from the following articles:

• Introducing apko: bringing distroless nirvana to Alpine Linux
• Minimal Container Images: Towards a More Secure Future
• Secure Your Software Factory with melange and apko

Support is provided on a best-effort basis via GitHub issues.

For commercial support, please see Chainguard.