Software bills of materials are now a procurement requirement in several markets and a routine deliverable in enterprise contracts. A supplier produces a file listing components and versions, attaches it to a release, and the obligation is met. The file is usually accurate. What nobody can prove is that the file is the one the supplier produced for that artefact.
An SBOM without a signature, and without a verifiable link to the artefact, is a description rather than evidence. It answers what the supplier intended to ship, and says nothing about what arrived.

What the formats already support

SPDX and CycloneDX both carry fields for provenance, and the ecosystem around them has tooling for signing. CycloneDX defines a signature property that can hold a JWS or an X.509 chain. The in-toto attestation format is designed for exactly this problem: bind a statement about an artefact to the artefact's digest, then sign the statement so a consumer can verify both.
The build platform matters more than the format. A signature is only useful if the signing step happens in a build system the consumer trusts, and if the artefact digest in the attestation is the digest the consumer actually receives. A signature produced on a laptop and uploaded next to an unsigned image proves only that the laptop produced a signature.
In-toto attestations produced by a CI system, with a signature verifiable against a public key the supplier publishes, convert an SBOM from a document into a claim that can be checked. SLSA provenance is the practical implementation of that idea.

The verification the consumer has to do

Four checks turn the document into a control, and each fails closed.
Verify the signature against the expected key or identity, and confirm the identity matches the supplier rather than any signer.
Confirm the subject digest in the attestation equals the digest of the artefact the consumer deployed. This is the check that catches a valid signature reused for a different image.
Confirm the builder identity. A statement about an artefact on a developer workstation is a weaker claim than one produced by the release pipeline, and the attestation normally records which.
Then reconcile the component list against the deployed image, by scanning the image and comparing the resulting component inventory with the claimed one. A component in the image but not in the SBOM is the case that matters, because it is the one that hides a dependency the supplier did not intend to disclose or did not know about.

The common failure modes

Signing the document but not the artefact digest. The signature is valid, the attestation is intact, and the binding is missing, so nothing prevents a substitution.
Publishing the key next to the signature without a trust root. A consumer who fetches both from the supplier's own server is trusting that server's integrity, which is what the supply chain attack would compromise first.
Producing the attestation after the artefact was built. A rebuild that changes one byte produces a different digest, and the attestation for the earlier build no longer describes what shipped.
Treating SBOM presence as compliance. The procurement checklist is satisfied and the consumer still cannot answer whether a vulnerable component is in the running image.

A workable sequence for a consumer

Start by requiring the digest binding for new releases, and accept unsigned documents only for existing inventory as a temporary state with a recorded end date.
Store the verified attestation and the artefact digest together at deployment time, so the record exists when an incident needs it.
Run the image scan and diff the result against the claimed component list. Automate the diff, because it is the only part of this process that finds undisclosed components.
Track which suppliers already sign and which do not. The list of suppliers without digest-bound attestations is a prioritisation input for procurement, and it is more actionable than a general statement that supply chain security matters.

Limits

A verified attestation proves the artefact was built by a specific pipeline and has not changed since. It does not prove the components listed are free of vulnerabilities, and it does not prove the build system was honest, only that it produced this statement. The gap between a signature and a secure build is where the remaining work sits.

References

  • in-toto attestation specification: https://github.com/in-toto/attestation

  • SLSA provenance specification: https://slsa.dev/spec/v1.0/provenance

  • CycloneDX specification, signature and provenance fields: https://cyclonedx.org/specification/overview/

  • SPDX specification: https://spdx.dev/use/specifications/

  • CISA, software bill of materials resources: https://www.cisa.gov/sbom