Automatic SBOMs with ko

For those unfamiliar with ko, it “is a simple, fast container image builder for Go applications;” its objective is to enable developers to stop worrying about containers, and focus on their application. The philosophy of ko aligns with our mission at Chainguard: to make the software supply chain secure by default. We aim to achieve this shared mission by making adoption of best practices the easy default way.

One of the emerging best practices in software supply chain security right now is the Software Bill of Materials (aka SBOM), which captures the set of materials (e.g. dependencies) that were used to produce a particular piece of software (e.g. a container image). The latest release of ko embraces this best-practice and automatically produce an SBOM for your Go application:

$ KO_DOCKER_REPO=ghcr.io/mattmoor ko build -B ./test/
2022/02/08 16:02:13 Using base gcr.io/distroless/static:nonroot for github.com/google/ko/test
...
2022/02/08 16:02:16 ghcr.io/mattmoor/test:sha256-9fea1484646ee13d9f0597e68f0714eb22d2a92a237d9fc368fd0af25a3971ba.sbom: digest: sha256:3c482496de3561002356b6c41edac5c01da44a3d3ae7ffcbcab6a6895db12f7e size: 368
2022/02/08 16:02:16 Published SBOM ghcr.io/mattmoor/test:sha256-9fea1484646ee13d9f0597e68f0714eb22d2a92a237d9fc368fd0af25a3971ba.sbom
...
2022/02/08 16:02:19 ghcr.io/mattmoor/test:latest: digest: sha256:9fea1484646ee13d9f0597e68f0714eb22d2a92a237d9fc368fd0af25a3971ba size: 751
2022/02/08 16:02:19 Published ghcr.io/mattmoor/test@sha256:9fea1484646ee13d9f0597e68f0714eb22d2a92a237d9fc368fd0af25a3971ba
ghcr.io/mattmoor/test@sha256:9fea1484646ee13d9f0597e68f0714eb22d2a92a237d9fc368fd0af25a3971ba

You can disable SBOM generation by passing: --sbom=none.

The SBOM ko produces is based on the buildinfo functionality in Go, which you can see with:

go version -m <binary>

You can download the SBOM ko produces with Sigstore’s cosign via:

$ cosign download sbom $IMAGE_DIGEST
Found SBOM of media type: text/spdx
SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: github.com/google/ko
DocumentNamespace: http://spdx.org/spdxpackages/github.com/google/ko
...

ko produces SPDX-based SBOMs (above), but it can also produce CycloneDX with --sbom=cyclonedx.

You can also use the Kubernetes project’s bom tool to explore the downloaded SBOM:

├ github.com/google/ko
│ │ 🔗 1 Relationships
│ └ DEPENDS_ON PACKAGE github.com/google/go-containerregistry (version v0.8.1-0.20220207182237-33725

If you are using ko’s multi-arch functionality, you will get an SBOM for each architecture:

$ KO_DOCKER_REPO=ghcr.io/mattmoor ko build --platform=linux/amd64,linux/arm64 -B ./test/

2022/02/08 16:13:17 Using base gcr.io/distroless/static:nonroot for github.com/google/ko/test
2022/02/08 16:13:18 Building github.com/google/ko/test for linux/amd64
2022/02/08 16:13:18 Building github.com/google/ko/test for linux/arm64
...
2022/02/08 16:13:22 Published SBOM ghcr.io/mattmoor/test:sha256-9fea1484646ee13d9f0597e68f0714eb22d2a92a237d9fc368fd0af25a3971ba.sbom
...
2022/02/08 16:13:23 Published SBOM ghcr.io/mattmoor/test:sha256-ba6b7116ac0fdfa59c5a4df7471abd89d4e018a7088bcadb37669f5b0175d923.sbom
...

But wait, there’s more! SBOMs are not the only software supply chain best-practice making waves right now, there is also signing. This latest release does not YET incorporate verification or signing directly into ko, but it does add a feature that makes signing your ko-built images significantly easier: --image-refs.

‍

With --image-refs=<file>, ko will enumerate all of the image digests it publishes into <file>. This can be used directly with cosign to sign your container images via:

COSIGN_EXPERIMENTAL=true cosign sign $(cat <file>)

This new flag can also be used with Tekton Chains to attach SLSA provenance to the produced images.

‍

Finally, this blog post would not be complete without a shout-out to the folks that help make ko possible: Jon Johnson, Jason Hall, and the many folks that have contributed to ko over the years. THANK YOU.