Week 17 - Software Bill of Materials (SBOM)¶

17.1 Conceptual Core¶

An SBOM is a structured manifest of every component, dependency, and license in a software artifact. Two dominant formats: SPDX and CycloneDX. Both are JSON; both are interchangeable for most uses.
Three levels of SBOM accuracy:
Source SBOM-generated from go.mod, package.json, etc., before build.
Build SBOM-generated by the build tool (buildah, goreleaser, docker buildx).
Image SBOM-generated from a built image (Syft, Trivy). May differ from source SBOM if the build introduces or strips dependencies.
For compliance, ship the image SBOM attached to the image (as an attestation in the registry) and verify on consumption.

Syft (Anchore): syft <image> -o spdx-json > sbom.json. Inspects layers, identifies packages by ecosystem (apk, dpkg, rpm, npm, gomod, pip, gem, cargo, ...).
Trivy also generates SBOMs (trivy image --format cyclonedx), with overlapping but slightly different package detection.
OCI image artifacts-SBOMs can be attached to the image in the registry as separate artifacts via the OCI Reference Types specification. cosign attach sbom is the canonical command.

Generate an SBOM for one of your images with Syft (SPDX) and Trivy (CycloneDX). Diff the two-note where they disagree.
Attach the SBOM to the image with cosign attach sbom.
From a downstream consumer, retrieve and parse the SBOM with cosign download sbom.
Add a CI step that fails the build if the SBOM contains a known-bad license (e.g., AGPL in a closed-source project).

Build a script that diffs SBOMs between two image versions; produces a "what changed" report. Use this in PR review for image base-image bumps.

Require an attached SBOM for every image promoted to a prod/ registry path. Verify in CI before promotion.