SBOMs: generate, store, query

SPDX, CycloneDX, and the zero-day drill.

Advanced12 min · lesson 11 of 18

A Software Bill of Materials is a complete, machine-readable inventory of everything inside an artifact — every package, library, and version, direct and transitive. It is the "ingredients label" for your software, and its value is simple but enormous: you cannot secure or reason about what you do not know you are shipping. An SBOM turns "what is in this image?" from an unanswerable question into a file you can query. Two standard formats dominate: SPDX and CycloneDX.

SBOM LIFECYCLE: GENERATE TO QUERY
1Generate at build
syft, SPDX or CycloneDX, every artifact
2Sign & attach
cosign attest: travels with image, tamper-evident
3Store queryable
feed into inventory, searchable fleet-wide
4Query on demand
zero-day drill: which images ship pkg X@Y?
Bought on every build, cashed in on the worst day: CVE triage becomes a search, not an archaeology project.
terminal
$ syft "$IMAGE@$DIGEST" -o spdx-json > sbom.spdx.json # generate
$ syft "$IMAGE@$DIGEST" -o cyclonedx-json > sbom.cdx.json # or CycloneDX
# generate at BUILD time (you have the most context), for every artifact

Generate, store, and — crucially — query

An SBOM sitting in a build log is nearly useless; the value is in storing them so you can query across everything you run. Attach the SBOM to its image as a signed attestation (so it travels with the artifact and is tamper-evident), and/or feed SBOMs into an inventory system. Then the question "which of our artifacts contain package X at version Y?" is a search, not an archaeology project. Generate at build, sign it, store it queryably — that trio is what makes an SBOM operational rather than compliance theater.

terminal
# attach the SBOM to the image as a signed attestation (travels + tamper-evident)
$ cosign attest --yes --predicate sbom.spdx.json --type spdxjson "$IMAGE@$DIGEST"
# later, scan the SBOM (no need to re-pull/rebuild) against fresh CVE data:
$ grype sbom:sbom.spdx.json --fail-on high

The zero-day drill

The payoff arrives the day a critical CVE lands in a ubiquitous library — the Log4Shell moment. With signed, stored, queryable SBOMs, "are we affected, and exactly where?" is answered in minutes by querying your inventory for the vulnerable coordinates across every service. Without SBOMs, that same triage is days of manually rebuilding and grepping images while attackers are already scanning the internet. The SBOM is insurance you buy on every build and cash in on the worst day.

An SBOM you cannot query is a checkbox
Generating SBOMs to satisfy a policy and then dropping them in a bucket nobody searches provides no protection — the whole value is fast, fleet-wide lookup when it matters. Store them where you can query across all artifacts, keep them current (regenerate on rebuild), sign them so they are trustworthy, and actually run the drill: pick a recent CVE and time how fast you can list affected images. If that takes days, the SBOM program is not real yet.