Home / SBOM / SBOMs for Docker Images

Generate SBOMs for Docker Container Images with Syft

Updated on February 6, 2024
By: Anchore
Anchore Graphics
Navigate To
Close Table of Contents
Table of Contents
    Fast Facts

    What makes up an SBOM?

    • Complete inventory of a codebase
    • Identifying open source components
    • License and version information for open source components

    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.

    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.

    What is Syft?

    Syft is a 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. Anchore makes it easy to store, analyze, share, and manage SBOMs. 

    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.

    Book Cover for SBOM rol in cybersecurity thumbnail
    The Software Bill of Materials and its Role in Cybersecurity

    Download the White Paper

    How to use SBOMs to strengthen the security of your software supply chain for cloud-native applications

    Speak with our security experts

    Learn how Anchore’s SBOM-powered platform can help secure your software supply chain.