SBOMs with Syft

SPDX/CycloneDX, signed and attached by digest.

An SBOM — Software Bill of Materials — is the ingredient list for an artifact. When the next Log4Shell-scale vulnerability drops, the difference between "we know exactly where we are affected in minutes" and "we spend a week grepping" is whether you generated SBOMs.

Formats and generation

An SBOM is a machine-readable inventory of every component and dependency in an artifact, expressed in a standard format — SPDX or CycloneDX are the two dominant ones. Tools like Syft generate an SBOM by cataloging what is actually present in an image or filesystem: OS packages, language dependencies, and their versions. Generate it at build time, when you have the most accurate view of what went in, and attach it to the artifact as a signed attestation so it travels by digest and can be verified later rather than living as a detached, forgeable side file.

# Generate a CycloneDX SBOM from the built image:
syft registry.acme.internal/api@sha256:9f2c... -o cyclonedx-json > sbom.json
 
# Attach it as a signed in-toto attestation (travels with the image by digest):
cosign attest --predicate sbom.json --type cyclonedx \
  registry.acme.internal/api@sha256:9f2c...
# Now the SBOM is verifiable evidence, not a file that could be swapped out.

Scanning, VEX, and staying current

The SBOM is the input to vulnerability scanning: Grype (or Trivy) matches the component list against vulnerability databases to report known CVEs — and because the SBOM is stored, you can re-scan an old artifact against today’s vuln data without rebuilding it. VEX (Vulnerability Exploitability eXchange) documents cut the noise by asserting whether a reported vulnerability is actually exploitable in your context, so teams triage real risk instead of a wall of "found in a dependency we never call". Together, SBOM + scanning + VEX turn "what are we running and are we exposed?" from a fire drill into a query.