Skip to content

Syft: record the contents of every image

Security · SBOM
Not studied

Added 2026-10-11. Requires Syft, Docker and an already built local image.

Problem

A new CVE appears, and the contents of an old release image are unknown. The tag has already been moved to another build, and the original container is gone.

Solution

Syft is "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems", "exceptional for vulnerability detection when used with a scanner like Grype". Generate the SBOM — a list of detected components — at build time and store it together with the image identifier. Syft produces the inventory; CVE matching is done by a separate scanner. Having an SBOM doesn't mean there are no vulnerabilities, nor does it prove the image's provenance.

Example

First set IMAGE_REF to the name of an image that was actually built. Using the local ID prevents accidentally analyzing a different build if the tag changes between commands.

#!/usr/bin/env bash
set -euo pipefail
: "${IMAGE_REF:?Set the local image to analyze}"

mkdir -p artifacts
image_id=$(docker image inspect --format '{{.Id}}' "$IMAGE_REF")
printf '%s\n' "$image_id" > artifacts/image-id.txt
syft version > artifacts/syft-version.txt
syft "docker:$image_id" \
  -o cyclonedx-json=artifacts/sbom.cdx.json \
  -o syft-json=artifacts/sbom.syft.json
test -s artifacts/sbom.cdx.json

In CI, upload the three reports and the ID file to the artifacts of the corresponding release. The local Docker image ID is the config digest, not the registry manifest digest. After publishing, separately store the registry digest from the push output; for a multi-platform image, account for the contents of each platform. Don't present the local ID as proof that this exact manifest was published.

CycloneDX is convenient for exchange; Syft's own JSON keeps extra detail. Before feeding a report to a specific scanner, check which format version it supports. The inventory depends on recognized packages and the scan scope; manually compare a few expected components against the report.

When to use

For images that live longer than a single CI run, and for finding affected releases after a CVE appears. Complements Trivy in CI.

Source

How to apply it yourself

  1. Generate an SBOM for one release image and find the expected system packages and application dependencies in it.
  2. Check that the scanner you use can read the chosen format.
  3. Using the release ID, find the SBOM and the matching image digest after the CI working directory is gone.
  4. Once storage is set up and the report has been re-analyzed, mark it "Studied".