How to Generate SBOMs for Docker Images with the 'docker sbom' Command

An introduction to the ‘docker sbom’ command

Anchore and Docker teamed up to bring Docker users the ability to create software bill of materials (SBOM) directly in the native Docker CLI. Included in Docker Desktop is an operation called ‘docker sbom’. This new operation, which is built on top of Anchore’s open source Syft project, enables Docker users to quickly generate detailed SBOM documents against container images.

Why it matters

SBOMs are quickly becoming foundational data sources for a variety of DevSecOps use-cases, ranging from basic software development hygiene to more complex security measures. These include tamper and drift detection, zero-day response support, and post-security-event forensic analysis. While security scanning tools need to identify software components, they often don’t make an SBOM accessible to users or include the level of detail needed to support a variety of use cases. With this collaboration between Anchore and Docker, we are giving users the ability to create and store an SBOM independently from running any higher-level function like vulnerability scanning or license detection. We believe that the availability of SBOM data is foundational when developing processes and technologies to improve software supply chain security.

Learn how to automate container vulnerability scanning in Harbor registry with Anchore Enterprise. A webinar with the experts from Anchore.

Watch Now

The Open Source Tool for Generating Docker SBOMs

Syft is an open source software bill of materials (SBOM) generator designed to scan container images and filesystems to create an inventory of their contents, including files and software packages. With a focus on speed, accuracy, and ease of integration, Syft aims to provide the best choice for developers and DevOps engineers who need to integrate container scanning into their CI/CD pipelines. While Syft excels at detecting packages handled by package managers, it also has the ability to detect binaries installed outside of package managers with the goal of bringing supply chain visibility to all applications and dependencies regardless of whether they fit a specific development pattern.

If you’re interested in learning more about Syft, check out Anchore’s open source overview.

Benefits of ‘docker sbom’ command for securing container images

By enabling SBOM creation to be an independent operation, it can be decoupled from the multitude of individual use cases that rely on SBOM data. This approach gives users the ability to generate an SBOM once and then use it for a variety of use cases. We believe that the availability of SBOM data is foundational when developing processes and technologies to improve software supply chain security. With ‘docker sbom’, we’re excited to engage with the Docker and Anchore communities together on the topic of SBOM creation, usage, and future directions.

By integrating SBOM generation directly into the Docker command line, Anchore and Docker demonstrate the importance of making SBOM generation a native user experience. We believe that SBOMs are not only a foundational element of secure software development, it is integral to Docker security best practices as well.

How to generate an SBOM for a Docker image

The new ‘docker sbom’ command is simple to use and leverages the power of Syft to provide rich content and data formats. In the following quick example, we show how the ‘docker sbom’ command can be used to generate a comprehensive SBOM document in a user-chosen format and then used as input for other tools that are capable of consuming an SBOM to provide higher-level functions such as vulnerability scanning.

As the discussion on the best way to create and consume SBOM data continues to evolve, we’re committed to supporting standard SBOM formats like SPDX, CycloneDX, Syft-JSON, and others in order to promote the idea of creating and storing SBOMs in forms that interoperate with evolving security and DevOps infrastructure tools.

Here, we show using the ‘docker sbom’ command against a test image that combines regular distro-provided packages (Alpine in this case) with multiple vulnerable versions of Log4j that are packaged in a variety of different forms ranging from simple top-level jars to many-levels-deep jars within compressed Java archives:

% docker sbom dnurmi/testrepo:jarjar

Syft v0.42.2

 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [217 packages]

NAME                         VERSION                        TYPE

alpine-baselayout            3.2.0-r18                      apk
alpine-keys                  2.4-r1                         apk
…
…
log4j-core                   2.12.1                         java-archive
log4j-core                   2.11.0                         java-archive
log4j-core                   2.11.1                         java-archive
log4j-core                   2.13.2                         java-archive
log4j-core                   2.12.0                         java-archive
…

While the default output is in human-readable form for quick review, the command supports a growing set of output formats that can be used more directly for integration into other systems and tools that can analyze SBOMs:

% docker sbom --help


Usage:  docker sbom [OPTIONS] COMMAND

…
      --format string       report output format, options=[syft-json cyclonedx-xml cyclonedx-json github-json spdx-tag-value spdx-json table text]

                              (default "table")
…

To demonstrate this flow, let’s look at a simple use case where ‘docker sbom’ is used to produce its data as SPDX JSON, which is then consumed by another tool. We’ll use Grype, Anchore’s open source vulnerability scanner, to produce a vulnerability report without needing to contact any remote scanning services:

% docker sbom --format spdx-json docker.io/dnurmi/testrepo:jarjar | grype

Syft v0.42.2

 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [217 packages]

NAME                 INSTALLED     FIXED-IN      VULNERABILITY        SEVERITY

…
log4j-core           2.12.1                      CVE-2021-45046       Critical
log4j-core           2.11.0                      CVE-2021-45105       Medium
log4j-core           2.13.2        2.16.0        GHSA-7rjr-3q55-vv33  Critical
log4j-core           2.12.1        2.12.4        GHSA-8489-44mv-ggj8  Medium
log4j-core           2.13.0                      CVE-2020-9488        Low
log4j-core           2.12.1        2.12.3        GHSA-p6xc-xr62-6r2g  High
log4j-core           2.12.0        2.12.3        GHSA-p6xc-xr62-6r2g  High
log4j-core           2.12.0                      CVE-2021-44832       Medium
…

Manage SBOMs and automate container scanning with Anchore

Generating an SBOM is just part of the equation. Storing, analyzing, sharing, and managing SBOMs at scale is a whole other story entirely, and a process that development teams should strive to automate and integrate into their DevSecOps pipelines.

Anchore provides a number of open-source and commercially available software tools for managing SBOMs and providing security/compliance insights and enforcement capabilities against those generated SBOMs:

Our general approach to securing modern software development systems embraces the user’s automation and development flexibility objectives, handling large and dynamic software production flows. To facilitate this, the Anchore Enterprise platform effectively conforms to a pattern where:

Existing software development infrastructure is instrumented with light-weight tooling that is pointed at a software element (source code checkout, container image, etc.) to generate an SBOM, and then
The tooling imports that SBOM into a deployment of Anchore Enterprise which stores the SBOM for further processing, at which point the full capabilities of Anchore Enterprise can be applied to the software SBOM.

The Anchore Enterprise client that implements the SBOM generation and import steps is named ‘anchorectl’, a lightweight CLI tool that is included with the Anchore Enterprise platform.

As part of our ongoing commitment to support integration with Docker’s native tooling and approach to SBOM generation, we’ve recently released a new version of anchorectl, available to all Anchore Enterprise users, with added support for importing an SBOM directly from new ‘docker sbom’ command. With this capability, users who have access to an existing Anchore Enterprise deployment and prefer to use native ‘docker’ commands in their development environments can easily connect the two systems in a typically UNIX-like fashion. The following example shows an abstract ‘checkout, build container image, import image sbom to Anchore Enterprise’ using this new interface.

…
# git clone <somerepo>

# docker build -t <someimage> -f <somerepo>/Dockerfile <somerepo>/

# docker sbom --format syft-json <someimage> | anchorectl sbom upload -
…

With this simple process invoked either manually or scripted as part of an automated build, users can be assured that new container image SBOMs are being imported to their Anchore Enterprise deployment, so that the full capabilities of Anchore Enterprise – vulnerability scanning (on demand, historical), cybersecurity compliance checks using Anchore’s fully policy subsystem, SBOM drift detection, global reporting and notifications, and many others – can be applied.