How to Improve Docker Security with ‘docker sbom’ and Syft
Docker has introduced a new docker sbom
command that gives Docker Desktop users a powerful tool in the native Docker CLI to quickly generate a detailed software bill of materials, or SBOM, for container images. The command is built on top of the open source project Syft, which is maintained by Anchore.

An SBOM identifies every artifact in a container image, making it easier to pinpoint vulnerabilities in your software supply chain and quickly remediate them at any stage of the software development life cycle.
There are multiple ways to use an SBOM to improve Docker security:
- Generate a single source of truth for all container artifacts.
- Aggregate SBOMs for individual container images to gain an application-level view.
- Uncover unexpected dependencies, malicious efforts to infiltrate builds and inadvertent errors.
- Perform vulnerability scanning across all life cycle stages.
- Create and enforce policies based on rich SBOM data.
- Meet customer and federal compliance requirements.
Why Docker Security Starts with the SBOM
The SBOM’s role in securing container images is foundational — it functions like an ingredients list for each stage of the development life cycle so you always know exactly what’s in your container image and when and where it was introduced.
A software supply chain is complex, and each application can have hundreds or even thousands of dependencies that might not be obvious or visible to you. The true value of SBOM data is knowing in real time where the security issues are in your software supply chain.
Because vulnerabilities can be introduced at any stage in the development cycle, you’ll want to generate an SBOM for each of the source, build, stage, deploy and run stages to produce a complete record of artifacts. Then you can use the SBOMs to check for anomalies in your container images over time and to jumpstart forensic analysis should you need to remediate a vulnerability. The docker sbom
command functions in the critical build stage and provides capabilities that enable you to generate SBOMs within your native Docker development environment.
SBOM Formats and Use Cases
As a foundational data source for development and security teams, SBOMs are valuable for a range of use cases from basic software development hygiene to complex security and compliance management focused on tamper and drift detection, zero-day remediation, forensic analysis and more.
Although you can use security scanning tools to identify software components, they often don’t make an SBOM accessible to you or include the level of detail needed to support a variety of use cases. The open source collaboration between Docker and Anchore gives you the ability to create and store an SBOM independently from such actions as vulnerability scanning or license detection.
Beneath the hood, the docker sbom
command leverages Syft’s use of industry-standard formats like SPDX, CycloneDX, Syft-JSON and others to create and store SBOMs that interoperate with evolving security and DevOps infrastructure tools.
Your use case will determine which SBOM format to use. For example, if interoperability with other tools is important, you can choose SPDX or CycloneDX as your standard format for distributing SBOMs to downstream customers. Syft also provides a native SBOM format for lossless interoperability with the Grype vulnerability scanner.
The docker sbom
Command in Action
The new docker sbom
command is simple to use and leverages the power of Syft to generate rich SBOM content in a variety of data formats that other tools can ingest to perform critical security actions like vulnerability scanning.
In this example, the docker sbom
command is executed against a test image that combines standard distro-provided packages (I used Alpine here) with several vulnerable versions of Log4j that are packaged in a variety of different forms ranging from top-level jars to multiple-levels-deep jars within compressed Java archives:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
% 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 … |
The “docker sbom” command supports a growing set of output formats that directly integrate into other systems and tools that analyze SBOMs, but the default output is in a human-readable format:
1 2 3 4 5 6 7 8 9 10 11 12 |
% 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 how the command works, here’s a simple use case where “docker sbom” is used to produce its data as SPDX JSON for consumption by Anchore’s open source vulnerability scanner Grype to generate a vulnerability report:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
% 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 … |
As you can see, the new “docker sbom” command is a powerful feature for quickly generating SBOMs that can be ingested by security tools you already use. SBOMs are foundational to container security, giving you the ability to more quickly pinpoint and remediate security risks that can enter at any stage of the development process. The docker sbom
command is now available to all users of Docker Desktop.