Secure · SBOM generation
Syft
Syft catalogs the packages inside container images, filesystems and source trees and emits software bills of materials in CycloneDX, SPDX and its own JSON format for downstream scanning and attestation.
On this page
What it does
Inventories OS packages and language dependencies (npm, pip, Go modules, Java, Rust, .NET and more) and writes a standards-compliant SBOM.
Where it fits
Secure and Package: generate an SBOM for every built image and attach it to the release (cosign attach sbom) so it can be re-scanned
as new CVEs appear.
Quick start
syft registry.example.com/app:1.2.3 -o cyclonedx-json=app.cdx.json
syft dir:. -o spdx-json=source.spdx.jsonCommon pitfalls
- Compiled-only images (no lockfiles, no package DB) produce thin SBOMs; keep metadata in the final stage or generate from source.
- Pin the output schema version (
cyclonedx-json@1.5) when a downstream tool is strict.
On this site
- Generate an SBOM with Syft in the Software Supply Chain Security path: a real image, the 234-package inventory and why one dependency became 211.
Hands-on labs using Syft
Generate an SBOM with Syft and Scan It with Grype
Produce CycloneDX and SPDX bills of materials for a container image without a Docker socket, scan the SBOM with Grype, gate on fixable findings only, and see why the SBOM is worth keeping after the release.
Articles about Syft
Generate an SBOM with Syft and Read What It Tells You
Run Syft from its container against a small Node.js image, read the CycloneDX output package by package, see where each one came from, learn what an SBOM does not prove, and store it next to the artifact.