Today Anchore and Docker released the first feature in what we anticipate will be an ongoing initiative to bring the value of the software bill of materials (SBOM) to all container-oriented build and publication systems. Now included in the latest Docker Desktop version is an operation called ‘docker sbom’ that is available via the ‘docker’ command. 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 using the native Docker CLI.
SBOMs are quickly becoming foundational data sources for a variety of DevSecOps use cases ranging from basic software development hygiene all the way to unlocking more complex security and compliance capabilities such as 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 open source 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.
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.
How the ‘docker sbom’ command works
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 industry standard 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
…
What’s next for Anchore and Docker collaboration
The process above demonstrates a vulnerability scan as just one example use case where SBOMs can prove valuable. At Anchore, we’ve built our open source projects and our commercial Anchore Enterprise solution using SBOMs as the foundation for enabling best practices for software development, security, and compliance. We’re committed to continuing this work by making available both open source projects and commercial Anchore Enterprise products that are built to create, ingest, store, analyze, and output SBOM data across all stages in the development cycle.
With Docker, we’re looking forward to further collaboration to deliver deeper integration between Syft’s SBOM generating technology and the Docker build and store processes. We are working toward a near future where every container image stored in a registry has an associated SBOM that can be inspected and consumed for further processing. And beyond that, we’re looking to explore ideas that couple build directives with SBOM content to drive concepts like reproducible builds and build time security rule enforcement. We’re excited to continue the discussion and to have you join us in this effort!
