Signing, provenance and SBOM, described mechanically

What does each artefact actually prove?

They answer different questions and are routinely conflated in procurement conversations. A signature answers who built this. A provenance attestation answers how and from what source it was built. An SBOM answers what is inside it. A VEX statement answers whether a known vulnerability affects it. None answers whether the software is secure, and a supplier who implies otherwise is worth pressing on.

Where does an SBOM have to be generated to be useful?

Inside the build, from the dependency resolution the build actually performed. An SBOM produced by scanning a finished artefact is a reconstruction: it identifies what a tool can recognise in the output, misses statically linked and vendored code, and cannot see build-time components that shaped the result. An SBOM produced by the build knows exactly which versions were resolved, because it was there when they were.

Depth is the next property to check. A list of direct dependencies is much less useful than the full transitive graph, because the components that cause incidents are usually several levels down and were chosen by a resolver rather than a person. When a supplier gives you an SBOM, check that transitive dependencies appear and that each entry carries a version and a machine-matchable identifier. Names alone are close to useless for matching.

The two formats you will meet are SPDX and CycloneDX, both standardised and widely supported. The choice matters less than consistency: pick one internally, convert at the boundary if a customer wants the other, and store the document with the artefact under the same retention. An SBOM you cannot retrieve for the version running in production has no operational value.

How does artefact signing work now?

Increasingly without long-lived keys. The pattern that has become common uses the build system's own workload identity: the pipeline presents a signed token asserting which repository and workflow is running, a certificate authority issues a short-lived certificate bound to that identity, the artefact is signed with it, and the signature is recorded in a transparency log. Nothing durable needs storing, which removes the key management problem that made signing unpopular for two decades.

The consequence is what verification then checks. You are no longer checking that a signature matches a key you hold, but that the signing identity is the specific repository and workflow you expect, which is stronger and easier to get wrong. A policy accepting any valid signature from a public log accepts a signature from anyone at all, and that is the most common misconfiguration here.

So write the verification policy explicitly: this image must be signed by this identity, from this source repository, on this reference, using this builder. Then test it by attempting to deploy something signed by a different workflow and confirming refusal. A signing programme that has never rejected anything has not been demonstrated to work.

What does provenance add beyond a signature?

It links the artefact back to the inputs, so you can answer whether the thing running in production came from the commit you reviewed. A signature tells you your pipeline produced it. Provenance tells you which revision, which build parameters and which builder produced it, which is what you need after any incident involving a compromised dependency or a modified build step.

The commonly referenced framework here is SLSA, which describes build levels of increasing strength. The distinction that matters is between provenance a project generates about itself, which anyone able to modify the build can also modify, and provenance the build platform generates in a way the build's scripts cannot forge. That is the question to ask a supplier, rather than which level number they claim.

The related property is reproducibility of inputs: dependencies pinned by digest, a pinned builder image, no unpinned network fetches during the build. Provenance describing a build that pulls the latest of something is documenting non-determinism.

Which of this is actually obligatory?

That depends on your jurisdiction, your sector and your customers, and it is a question for counsel rather than for a guide. The shape of the obligations is describable, though, and it now differs sharply between the two jurisdictions most buyers ask about.

In the United States the position changed in January 2026. OMB Memorandum M-26-05, of 23 January 2026, rescinded M-22-18 and its companion M-23-16, the memoranda that had required agencies to collect a CISA Common Form self-attestation of secure development practices before using third-party software. There is no government-wide attestation mandate now. Agencies set risk-based, agency-tailored assurance requirements instead, use of the Common Form is optional, and an attestation is collected only where an agency's own risk assessment calls for one. So both attestation and SBOM provision reach a federal supplier through the terms of an individual contract rather than through a common form, and M-26-05 contemplates terms requiring an SBOM of the runtime production environment on request.

In the European Union the duty is statutory rather than contractual. The Cyber Resilience Act obliges manufacturers of products with digital elements to maintain a machine-readable component inventory and report actively exploited vulnerabilities, phasing in with the reporting duties ahead of the full product requirements.

Sector standards add their own. Payment card requirements include an inventory of bespoke software and its third-party components, and medical device, automotive and industrial regimes each have component documentation expectations. In every case the operative text is the one your contract or your regulator points at, not a summary of it.

The practical reading is that generating SBOMs and provenance is becoming a condition of selling to regulated buyers, on a timetable set by whoever you sell to. Build the capability because it is a procurement requirement heading towards you, and have the specific obligations confirmed by someone accountable for the answer.

What is the minimum that is worth having?

Four things, in this order. Every artefact signed at build with a workload identity rather than a stored key. A verification policy at the deployment boundary that names the expected signing identity and refuses anything else. An SBOM generated by the build, stored with the artefact and retrievable by version. And provenance generated by the build platform, checked by the same admission policy.

Treat the first two as one item, because signing without verification is a filing exercise and verification without signing is impossible. Everything else in this area increases what you know; that pair decides what can run.

The test to run this week: take the newest artefact in your production registry and try to answer, from stored data alone, which commit produced it, who signed it, and what its dependency list was at build time. If any of those requires asking a person, that is the gap, and it is the same gap that turns a supply chain incident into a fortnight of archaeology.