docker sbom is gone: how to generate an SBOM from a Docker image now

docker sbom is gone. Its repository was archived on 19 May 2026, and the README now says the command has been removed and to use docker scout sbom instead. If a script of yours still calls it, you have three drop-in replacements: docker scout sbom to stay inside Docker's tooling, Syft if you want the engine the old command was wrapping, or Trivy if it is already in your pipeline.

This post gives the command for each, the flags that map onto the old ones, how to attach the SBOM at build time instead, and why the same image gives you three different package counts.

What happened to docker sbom

docker sbom arrived in 2022 as an experimental CLI plugin. It bundled Syft and exposed a few of its flags: --format, --output, --platform. Docker then built Docker Scout, gave it its own sbom subcommand, and deprecated the plugin. On 19 May 2026 the repository was archived. Its README is one heading, "Discontinued", and one sentence: the docker sbom command has been removed, please use docker scout sbom.

Nothing about your images changed. What changed is that a CI job calling docker sbom on a fresh runner now fails with "not a docker command", and a laptop that still has the old plugin binary runs catalogers frozen at whatever Syft version the plugin last shipped.

The replacement commands

# Before: the removed plugin
docker sbom --format cyclonedx-json --output nginx.cdx.json nginx:1.27-alpine

# Same ecosystem: Docker Scout
docker scout sbom --format cyclonedx --output nginx.cdx.json \
  --platform linux/amd64 nginx:1.27-alpine

# Same engine: Syft, which docker sbom was wrapping
syft scan --platform linux/amd64 -o cyclonedx-json=nginx.cdx.json \
  registry:docker.io/library/nginx:1.27-alpine

# Already in your pipeline: Trivy
trivy image --platform linux/amd64 --format cyclonedx \
  --output nginx.cdx.json nginx:1.27-alpine

The flags map one to one, with the format names spelled differently per tool:

docker scout sbom: stay inside Docker's tooling

docker scout sbom is part of the Scout CLI plugin. It outputs list, json (Scout's own format, the default), spdx or cyclonedx, reads local images, registries, OCI layout directories, docker save tarballs and plain directories, and takes --platform for multi-arch images.

# Docker Desktop 4.17 and later ship it. Elsewhere, macOS and Linux:
curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh -s --

# registry:// reads straight from the registry; no Docker Engine needed
docker scout sbom --format cyclonedx --platform linux/amd64 \
  --output nginx.cdx.json registry://docker.io/library/nginx:1.27-alpine

# a plain package list, optionally one package type
docker scout sbom --format list --only-package-type apk nginx:1.27-alpine

One behaviour to know about: when the image carries an SBOM attestation, Scout uses it instead of analysing the layers. On nginx:1.27-alpine it printed "SBOM obtained from attestation, 83 packages found" and wrote CycloneDX 1.5. That is fast and it is the publisher's own statement of contents, but the count and the component detail depend on whatever generator the publisher ran at build time, not on Scout. See why the counts differ below.

Best for: teams already using Scout in Docker Desktop, Docker Hub or CI. Scout's strengths are elsewhere: layer-level attribution and base-image recommendations, as the Docker Scout page describes.

Syft: the same engine, no Docker involved

docker sbom was Syft with a different front door, so Syft is the closest drop-in and the one whose output will look most like what you had. It is a single binary, pulls from a registry with your existing credentials, and writes CycloneDX, SPDX or its own JSON.

# CycloneDX, pinned to spec version 1.6, straight from the registry
syft scan --platform linux/amd64 -o cyclonedx-json@1.6=nginx.cdx.json \
  registry:docker.io/library/nginx:1.27-alpine

# SPDX instead
syft scan --platform linux/amd64 -o spdx-json=nginx.spdx.json \
  registry:docker.io/library/nginx:1.27-alpine

# an image already in your local daemon, or a docker save tarball
syft scan docker:nginx:1.27-alpine -o cyclonedx-json
syft scan docker-archive:nginx.tar -o cyclonedx-json

# convert what you already have
syft convert nginx.cdx.json -o spdx-json=nginx.spdx.json

On nginx:1.27-alpine for linux/amd64, Syft 1.42.1 wrote CycloneDX 1.6 with 68 library components, one operating-system component (Alpine) and 978 file entries recording where each package's binaries live, in seven seconds. The same command with -o spdx-json gave SPDX 2.3 with 69 packages. The first form is the exact command behind the downloadable example on our CycloneDX page.

Best for: anyone replacing docker sbom in a script, and anyone who wants the SBOM that the rest of the tooling expects: Grype reads it directly, and it is what the StackRadar scanner generates, unmodified, for every image a cluster runs. The SBOM tools comparison covers Syft against the alternatives in more depth.

Trivy: an SBOM from the scanner you already run

If Trivy is already in your pipeline, you do not need a second tool. --format cyclonedx or --format spdx-json turns an image scan into an SBOM, and trivy sbom scans that document later without pulling the image again.

trivy image --platform linux/amd64 --format cyclonedx \
  --output nginx.cdx.json nginx:1.27-alpine
trivy image --format spdx-json --output nginx.spdx.json nginx:1.27-alpine

# later: scan the document instead of pulling the image again
trivy sbom nginx.cdx.json

Pin the Trivy version or image digest you install. Its release binaries, images and trivy-action tags were compromised for a few days in March 2026 (GHSA-69fq-xp46-6x23), which is a good reason to pin any scanner you run in CI. Trivy vs Grype compares it with Syft's sibling scanner.

Or attach the SBOM when you build the image

For images you build yourself, the better answer is to stop generating the SBOM after the fact. BuildKit can generate one during the build, using a Syft-based plugin, and attach it to the image manifest as an in-toto attestation. That is what Scout found on the nginx image above.

# attach an SBOM attestation to the image you push
docker buildx build --sbom=true --tag registry.example.com/checkout:1.4.2 --push .

# read it back later
docker buildx imagetools inspect registry.example.com/checkout:1.4.2 \
  --format "{{ json .SBOM.SPDX }}"

# for a multi-platform image, one platform at a time
docker buildx imagetools inspect registry.example.com/checkout:1.4.2 \
  --format '{{ json (index .SBOM "linux/amd64").SPDX }}'

# or write it to disk instead of pushing: out/sbom.spdx.json
docker buildx build --sbom=true --output type=local,dest=out .

The attestation is SPDX by default. Anyone who pulls the image can read it with docker buildx imagetools inspect, and Scout, Grype and Trivy can consume it. The limit is in the sentence: it covers the images you build. The ingress controller, the CNI plugin, the monitoring agents and every other image you pull still need one of the three commands above.

Why the same image gives three counts

Syft and Trivy agree because they looked at the same apk database in the same layers. Scout reports a different number because it did not look: it trusted the SBOM the image's publisher attached, generated by a different Syft version with a different configuration at build time. Neither number is wrong. They answer different questions, "what did the publisher say is in here" and "what is in here".

The count is also the least important property of the document. What matters downstream is whether each component carries a package URL, whether the operating system is recorded, and whether versions are written the way the distro writes them, because that is what a vulnerability matcher keys on. All three tools get that right for OS packages.

If the image is one of a hundred running in a cluster

Every command on this page takes one image you name. A Kubernetes cluster runs dozens or hundreds, most of them images nobody in your organisation built, and the set changes with every deploy. The step up from "an SBOM of this image" to "an SBOM of what we run" is listing the digests the kubelets report and running one of these tools once per digest. How to generate an SBOM from a running Kubernetes cluster is the script version. StackRadar does the same job continuously, with Syft, and keeps one dated SBOM per image per cluster outside etcd: the Kubernetes SBOM page explains how, and the live demo shows the result without an account.

Frequently asked questions