The latest release series of BuildKit, v0.11, introduces support for build-time attestations and SBOMs, allowing publishers to create images with records of how the image was built. This makes it easier for you to answer common questions, like which packages are in the image, where the image was built from, and whether you can reproduce the same results locally.
This new data helps you make informed decisions about the security of the images you consume — without needing to do all the manual work yourself.
In this blog post, we’ll discuss what attestations and SBOMs are, how to build images that contain SBOMs, and how to start analyzing the resulting data!
In this post:What are attestations?Getting the latest releaseAdding SBOMs to your imagesSupplementing SBOMsEven more SBOMs!Analyzing imagesGoing further
What are attestations?
An attestation is a declaration that a statement is true. With software, an attestation is a record that specifies a statement about a software artifact. For example, it could include who built it and when, what inputs it was built with, what outputs it produced, etc.
By writing these attestations, and distributing them alongside the artifacts themselves, you can see these details that might otherwise be tricky to find. To get this kind of information without attestations, you’d have to try and reverse-engineer how the image was built by trying to locate the source code and even attempting to reproduce the build yourself.
To provide this valuable information to the end-users of your images, BuildKit v0.11 lets you build these attestations as part of your normal build process. All it takes is adding a few options to your build step.
BuildKit supports attestations in the in-toto format (from the in-toto framework). Currently, the Dockerfile frontend produces two types of attestations that answer two different questions:
SBOM (Software Bill of Materials) – An SBOM contains a list of software components inside an image. This will include the names of various packages installed, their version numbers, and any other associated metadata. You can use this to see, at a glance, if an image contains a specific package or determine if an image is vulnerable to specific CVEs.
SLSA Provenance – The Provenance of the image describes details of the build process, such as what materials (like, images, URLs, files, etc.) were consumed, what build parameters were set, as well as source maps that allow mapping the resulting image back to the Dockerfile that created it. You can use this to analyze how an image was built, determine whether the sources consumed all appear legitimate, and even attempt to rebuild the image yourself.
Users can also define their own custom attestation types via a custom BuildKit frontend. In this post, we’ll focus on SBOMs and how to use them with Dockerfiles.
Getting the latest release
Building attestations into your images requires the latest releases of both Buildx and BuildKit – you can get the latest versions by updating Docker Desktop to the most recent version.
You can check your version number, and ensure it matches the buildx v0.10 release series:
$ docker buildx version
github.com/docker/buildx 0.10.0 …
To use the latest release of BuildKit, create a docker-container builder using buildx:
$ docker buildx create –use –name=buildkit-container –driver=docker-container
You can check that the new builder is configured correctly, and ensure it matches the buildkit v0.11 release series:
$ docker buildx inspect | grep -i buildkit
Buildkit: v0.11.1
If you’re using the docker/setup-buildx-action in GitHub Actions, then you’ll get this all automatically without needing to update.
With that out of the way, you can move on to building an image containing SBOMs!
Adding SBOMs to your images
You’re now ready to generate an SBOM for your image!
Let’s start with the following Dockerfile to create an nginx web server:
# syntax=docker/dockerfile:1.5
FROM nginx:latest
COPY ./static /usr/share/nginx/html
You can build and push this image, along with its SBOM, in one step:
$ docker buildx build –sbom=true -t <myorg>/<myimage> –push .
That’s all you need! In your build output, you should spot a message about generating the SBOM:
…
=> [linux/amd64] generating sbom using docker.io/docker/buildkit-syft-scanner:stable-1 0.2s
…
BuildKit generates SBOMs using scanner plugins. By default, it uses buildkit-syft-scanner, a scanner built on top of Anchore’s Syft open-source project, to do the heavy lifting. If you like, you can use another scanner by specifying the generator= option.
Here’s how you view the generated SBOM using buildx imagetools:
$ docker buildx imagetools inspect <myorg>/<myimage> –format "{{ json .SBOM.SPDX }}"
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "/run/src/core/sbom",
"documentNamespace": "https://anchore.com/syft/dir/run/src/core/sbom-a589a536-b5fb-49e8-9120-6a12ce988b67",
"creationInfo": {
"licenseListVersion": "3.18",
"creators": [
"Organization: Anchore, Inc",
"Tool: syft-v0.65.0",
"Tool: buildkit-v0.11.0"
],
"created": "2023-01-05T16:13:17.47415867Z"
},
…
SBOMs also work with the local and tar exporters. When you export with these exporters, instead of attaching the attestations directly to the output image, the attestations are exported as separate files into the output filesystem:
$ docker buildx build –sbom=true -o ./image .
$ ls -lh ./image
-rw——- 1 user user 6.5M Jan 17 14:36 sbom.spdx.json
…
Viewing the SBOM in this case is as simple as cat-ing the result:
$ cat ./image/sbom.spdx.json | jq .predicate
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
…
Supplementing SBOMs
Generating SBOMs using a scanner is a good first start! But some packages won’t be correctly detected because they’ve been installed in a slightly unconventional way.
If that’s the case, you can still get this information into your SBOMs with a bit of manual interaction.
Let’s suppose you’ve installed foo v1.2.3 into your image by downloading it using curl:
RUN curl https://example.com/releases/foo-v1.2.3-amd64.tar.gz | tar xzf – &&
mv foo /usr/local/bin/
Software installed this way likely won’t appear in your SBOM unless the SBOM generator you’re using has special support for this binary (for example, Syft has support for detecting certain known binaries).
You can manually generate an SBOM for this piece of software by writing an SPDX snippet to a location of your choice on the image filesystem using a Dockerfile heredoc:
COPY /usr/local/share/sbom/foo.spdx.json <<"EOT"
{
"spdxVersion": "SPDX-2.3",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "foo-v1.2.3",
…
}
EOT
This SBOM should then be picked up by your SBOM generator and included in the final SBOM for the whole image. This behavior is included out-of-the-box in buildkit-syft-scanner, but may not be part of every generator’s toolkit.
Even more SBOMs!
While the above section is good for scanning a basic image, it might struggle to provide more detailed package and file information. BuildKit can help you scan additional components of your build, including intermediate stages and your build context using the BUILDKIT_SBOM_SCAN_STAGE and BUILDKIT_SBOM_SCAN_CONTEXT arguments respectively.
In the case of multi-stage builds, this allows you to track dependencies from previous stages, even though that software might not appear in your final image.
For example, for a demo C/C++ program, you might have the following Dockerfile:
# syntax=docker/dockerfile:1.5
FROM ubuntu:22.04 AS build
ARG BUILDKIT_SBOM_SCAN_STAGE=true
RUN apt-get update && apt-get install -y git build-essential
WORKDIR /src
RUN git clone https://example.com/myorg/myrepo.git .
RUN make build
FROM scratch
COPY –from=build /src/build/ /
If you just scanned the resulting image, it wouldn’t reveal that the build tools, like Git or GCC (included in the build-essential package), were ever used in the build process! By integrating SBOM scanning into your build using the BUILDKIT_SBOM_SCAN_STAGE build argument, you can get much richer information that would otherwise have been completely lost.
You can access these additionally generated SBOM documents in imagetools as well:
$ docker buildx imagetools inspect <myorg>/<myimage> –format "{{ range .SBOM.AdditionalSPDXs }}{{ json . }}{{ end }}"
{
"spdxVersion": "SPDX-2.3",
"SPDXID": "SPDXRef-DOCUMENT",
…
}
{
"spdxVersion": "SPDX-2.3",
"SPDXID": "SPDXRef-DOCUMENT",
…
}
…
For the local and tar exporters, these will appear as separate files in your output directory:
$ docker buildx build –sbom=true -o ./image .
$ ls -lh ./image
-rw——- 1 user user 4.3M Jan 17 14:40 sbom-build.spdx.json
-rw——- 1 user user 877 Jan 17 14:40 sbom.spdx.json
…
Analyzing images
Now that you’re publishing images containing SBOMs, it’s important to find a way to analyze them to take advantage of this additional data.
As mentioned above, you can extract the attached SBOM attestation using the imagetools subcommand:
$ docker buildx imagetools inspect <myorg>/<myimage> –format "{{json .SBOM.SPDX}}"
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
…
If your target image is built for multiple architectures using the –platform flag, then you’ll need a slightly different syntax to extract the SBOM attestation:
$ docker buildx imagetools inspect <myorg>/<myimage> –format "{{ json (index .SBOM "linux/amd64").SPDX}}"
{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
…
Now suppose you want to list all of the packages, and their versions, inside an image. You can modify the value passed to the –format flag to be a go template that lists the packages:
$ docker buildx imagetools inspect <myorg>/<myimage> –format ‘{{ range .SBOM.SPDX.packages }}{{ println .name .versionInfo }}{{ end }}’ | sort
adduser 3.118
apt 2.2.4
base-files 11.1+deb11u6
base-passwd 3.5.51
bash 5.1-2+deb11u1
bsdutils 1:2.36.1-8+deb11u1
ca-certificates 20210119
coreutils 8.32-4+b1
curl 7.74.0-1.3+deb11u3
…
Alternatively, you might want to get the version information for a piece of software that you know is installed:
$ docker buildx imagetools inspect <myorg>/<myimage> –format ‘{{ range .SBOM.SPDX.packages }}{{ if eq .name "nginx" }}{{ println .versionInfo }}{{ end }}{{ end }}’
1.23.3-1~bullseye
You can even take the whole SBOM and use it to scan for CVEs using a tool that can use SBOMs to search for CVEs (like Anchore’s Grype):
$ docker buildx imagetools inspect <myorg>/<myimage> –format ‘{{ json .SBOM.SPDX }}’ | grype
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
apt 2.2.4 deb CVE-2011-3374 Negligible
bash 5.1-2+deb11u1 (won’t fix) deb CVE-2022-3715
…
These operations should complete super quickly! Because the SBOM was already generated at build, you’re just querying already-existing data from Docker Hub instead of needing to generate it from scratch every time.
Going further
In this post, we’ve only covered the absolute basics to getting started with BuildKit and SBOMs — you can find out more about the things we’ve talked about on docs.docker.com:
Read more about build-time attestations
Learn about how to use buildx to create SBOMs
Implement your own SBOM scanner using the BuildKit SBOM protocol
Dive into how attestations are stored in the registry
And you can find out more about other features released in the latest BuildKit v0.11 release here.
Quelle: https://blog.docker.com/feed/
Published by