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:
go version -m <binary>
$ 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 ...
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=<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>)
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.