Generate an SBOM for any container image with Syft
Produce a complete software bill of materials in SPDX or CycloneDX and feed it to Grype for fast CVE triage.
You cannot patch what you cannot name. A container image is layers of OS packages, language dependencies, and static binaries — most teams know their app deps and have no inventory of what the base image dragged in. Syft catalogs everything inside an image or filesystem in seconds and emits SPDX or CycloneDX SBOMs that Grype, Dependency-Track, and admission policies consume without custom glue.
You will scan a running registry tag locally, export standard-format SBOMs in CI, triage CVEs against the SBOM instead of re-pulling the image on every scan, and archive one SBOM per build digest. Pairing Syft with Cosign attestations is the next step — both live in Software supply chain security.
Scanning sbom:path is faster and more reproducible than scanning the image tarball on every pipeline stage.
See what is actually in the image
Syft works on local tarballs, registry references, and directories — no Dockerfile required. It discovers packages across apk, dpkg, rpm, npm, pip, gems, and more. Run it in CI immediately after build so the SBOM matches the exact bytes you pushed, not a best-effort manifest from last month.
syft acme/api:1.4.0NAME VERSION TYPEopenssl 3.1.4-r5 apkexpress 4.19.2 npmcataloged 214 packages across 3 ecosystemsbase image packages often dominate the CVE countEmit a standard format
Pick CycloneDX or SPDX and stay consistent org-wide so downstream tools do not need adapters per team. JSON is the usual CI interchange format; SPDX tag-value still appears in compliance exports. Name artifacts with the image digest so tags moving does not overwrite history. Upload SBOMs to your artifact registry or object store with the same retention policy you use for the image itself — losing the SBOM when the image ages out defeats the purpose of archiving.
IMAGE=ghcr.io/acme/api@${DIGEST}syft "$IMAGE" -o cyclonedx-json > "sbom-${DIGEST#sha256:}.cdx.json"syft "$IMAGE" -o spdx-json > "sbom-${DIGEST#sha256:}.spdx.json"
Triage against the SBOM fast
Grype can scan sbom:sbom.cdx.json directly — same vulnerability data, no second registry pull, easy to re-run when the advisory database updates without rebuilding. Fail the pipeline on HIGH and CRITICAL for merge gates; track MEDIUM in a ticket queue so noise does not train developers to ignore scans. When a fix exists only in a newer base image, the SBOM tells you exactly which Dockerfile FROM line to bump instead of guessing from a CVE title alone.
grype sbom:sbom.cdx.json --fail-on highopenssl 3.1.4-r5 CVE-2024-6119 (High) fixed in 3.1.4-r6grype sbom:sbom.cdx.json -o table | head -20re-scan same SBOM when grype DB updates — no rebuildWhere this goes next
Archive SBOMs, attach them as Cosign attestations on the same digest, and teach admission controllers to require both a signature and a CycloneDX attestation before schedule. That closes the loop from catalog to enforceable policy. Software supply chain security covers Syft, Grype, signing, and verification through to the cluster.
Go deeper in a courseSoftware supply chain securitySBOM generation, vulnerability triage, provenance, and signing.View course