This is part six of Ship the Proof. The previous part attached a bill of materials to a digest as a matter of process. This part asks the harder question: what makes that bill of materials worth producing at all, now that no regulation requires it?

A vulnerability advisory lands for a transitive dependency you have never heard of. Someone asks the only question that matters: are we running it, and where? If your answer is “let me rebuild every image and rescan,” you have already lost the afternoon. A software bill of materials exists to make that question answerable in seconds instead of hours. Most fail at it, because they are generated against a moving tag, stored in a wiki, and never looked at again.

A useful bill of materials has three properties. It is in a format your tools actually read. It is bound to the exact artifact that ran, not to a tag that has since moved. And it is re-scannable without a rebuild. Get those three right and the document stops being a compliance checkbox and becomes an incident-response asset.

Declare a format and mean it

There are two formats worth considering, and you should pick one as your house standard rather than emitting both and hoping consumers cope.

CycloneDX 1.7 is the current release, published 21 October 2025, superseding 1.6 (cyclonedx.org). It leans toward security and dependency analysis. SPDX is the other option, an international open standard, ISO/IEC 5962:2021, with SPDX 3.0 current (3.0.1 the latest point release) and 2.3 still the pragmatic choice for a lot of tooling because 3.0 adoption across scanners is uneven (spdx.dev). SPDX leans toward licensing and is the one to reach for when you need an ISO-standard artifact.

The choice between them matters less than the commitment. Whatever you pick, write it down as the format your pipeline emits and your gates verify. A bill of materials nobody can parse is worse than none, because it looks like coverage while providing none.

If you report against a baseline, the NTIA 2021 minimum elements define seven fields: supplier name, component name, version, other unique identifiers, dependency relationship, author of the data, and a timestamp (SPDX NTIA HOWTO). CISA published a 2025 draft update to those minimum elements for public comment; it is a draft, not finalized guidance, so treat anything new it proposes as a direction of travel rather than a requirement (CISA).

Bind it to the digest, not the tag

The most common mistake is scanning the equivalent of myservice:latest. A tag is a mutable pointer. Between the moment you scan it and the moment you deploy, it can be re-pointed at a different image, and your document now describes something that is not running.

Generate against the content digest instead, then attach the result to that digest so it travels with the artifact. The first part of this series argued that the digest is the release identity, and this is one of the reasons: a bill of materials keyed to a digest is a claim that stays true, because the bytes it describes cannot change without changing the digest. One implementation, with the digest resolved first and the immutable reference scanned:

DIGEST=$(crane digest "$IMAGE:latest")     # sha256:...
syft "$IMAGE@$DIGEST" -o cyclonedx-json=./sbom.cdx.json

syft is one generator among several; the property that matters is that the scan target is the digest, not the tag, and that the output declares the format version you committed to. Attach it to the image as an OCI referrer (the same mechanism a signature uses), so a referrer-aware promotion carries it forward. Because referrers are separate manifests rather than image layers, a naive image-only copy leaves the bill of materials behind, the trap a promotion has to avoid.

Re-scan without rebuilding

Binding the document to a digest is what lets you answer the advisory question later without touching the build. Scan the stored bill of materials directly as the vulnerability database updates, rather than re-pulling and re-scanning the image:

grype sbom:./sbom.cdx.json

That runs in seconds against a document you produced weeks ago, with no registry pull and no rebuild. When the next advisory lands, you query your stored documents and get a list of affected digests immediately. That is the entire payoff, and it only works if the bill of materials was bound to a real, immutable identity in the first place.

One caution on tooling: scanners are not drop-in equivalents. They use different vulnerability databases and matching logic, and the same image can produce materially different findings between two of them, or even between two runs that read bills of materials from different generators. Pin your scanner and your generator together so results stay reproducible, and treat the choice as a real engineering decision rather than an implementation detail.

Why bother, now that nobody is forcing you

For a few years, the case for a bill of materials leaned on federal pressure. That scaffolding is gone. Executive Order 14306, signed 6 June 2025, amended the prior cybersecurity order and struck its centralized secure-software-development directives (whitehouse.gov). A subsequent Office of Management and Budget memorandum in January 2026 made secure-development attestations and bill-of-materials provision agency-discretionary and risk-based rather than mandatory. If your program was justified by “the government requires it,” that justification has evaporated.

It should not have been your reason anyway. The reason to produce a bill of materials is the advisory at the top of this post: you want to answer “are we running it, and where” in seconds. Customers in contract negotiations increasingly expect one. And the operational machinery (generate against the digest, attach as a referrer, re-scan without rebuild) pays for itself the first time a critical vulnerability lands in a dependency three levels down from anything you wrote. Produce it because it makes you faster during an incident, not because a memo told you to. The memo is gone. The incidents are not.

The next part is about those incidents directly: the supply-chain failures that became concrete in 2026, and the specific habits that defend against each.

Sources