BuildKit’s SBOM generation and provenance attestation features are incredibly powerful for understanding and verifying your software supply chain, but the real magic is how they integrate directly into your existing build process without requiring significant architectural changes.
Let’s see it in action. Imagine you’re building a simple Go application.
# Dockerfile
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o /app/myapp
FROM alpine:latest
COPY --from=builder /app/myapp /app/myapp
CMD ["/app/myapp"]
Now, to generate an SBOM and provenance attestation, you’ll use BuildKit’s buildx command. You’ll need to configure your buildx builder to enable these features.
First, ensure you have buildx installed and a builder set up. If not, create one:
docker buildx create --name mybuilder --use
docker buildx inspect --bootstrap
Next, enable the provenance and sbom features for your builder. You can do this by setting environment variables or directly in the buildx command. We’ll use environment variables for clarity:
export BUILDKIT_PROVENANCE=1
export BUILDKIT_SBOM=1
Now, build your image with the buildx build command, specifying the output format to include provenance and SBOM. We’ll output to Docker image format and also save the SBOM and provenance artifacts to disk.
buildx build \
--platform linux/amd64 \
--output "type=image,name=docker.io/your-dockerhub-username/my-go-app:latest,sbom=true,provenance=true" \
--output "type=local,dest=./build-artifacts" \
.
In this command:
--platform linux/amd64: Specifies the target architecture.--output "type=image,name=...,sbom=true,provenance=true": This is the core. It tells BuildKit to build a Docker image and, importantly, to embed both SBOM and provenance information directly into the image’s OCI manifest.sbom=trueandprovenance=trueare the key flags.--output "type=local,dest=./build-artifacts": This instructs BuildKit to also save the generated SBOM (in CycloneDX JSON format by default) and provenance attestation (in SLSA v1.0 format) as separate files in a local directory namedbuild-artifacts. This is useful for archiving or external analysis.
After the build completes, you can inspect the artifacts.
To view the SBOM file:
cat ./build-artifacts/sbom.json
This JSON file will detail all the software components (dependencies, base image layers, etc.) used in your image.
To view the provenance attestation:
cat ./build-artifacts/provenance.json
This file contains a cryptographically signed record of how the image was built, including the builder’s identity, the source code commit (if available), the build command, and the intermediate steps.
The real power here is that the provenance and SBOM are not just separate files; when type=image is used with sbom=true and provenance=true, BuildKit embeds these into the image’s OCI configuration. Tools that understand OCI can then extract this information directly from the image. For example, docker buildx imagetools inspect docker.io/your-dockerhub-username/my-go-app:latest will show these annotations.
This integration means your CI/CD pipeline can automatically generate these critical security artifacts for every build, providing an auditable trail of your software’s origins and composition. The system solves the problem of "trust" in the software supply chain by making the build process transparent and verifiable, without adding significant overhead or complexity to your existing Dockerfiles or build workflows. You’re not changing what you build, but how you record its creation.
The most surprising thing about how BuildKit generates provenance is that it doesn’t just record the final command. It actually traces and records the intermediate steps of the build, including the specific commands executed within each build stage and the artifacts produced by those commands. This granular detail allows for much more precise verification and attestation of the build process.
If you wanted to explicitly control the SBOM format (e.g., to SPDX instead of the default CycloneDX), you would add sbom-format=spdx to your output configuration.
The next step in understanding software supply chain security with BuildKit involves exploring how to verify these attestations automatically within your CI/CD pipeline, ensuring that only trusted, verified images are deployed.