Most organisations that tell me they have solved software supply chain security mean they generate an SBOM. When I ask where it goes, the answer is usually a build artefact store nobody has opened, or an attachment sent to a customer's procurement team once a year. An inventory that is never queried is not a control. It is a receipt.
The value in this whole area sits almost entirely in the verification step, and verification is the part that gets deferred because it is the only part that can break a deployment. That is precisely why it works.
This piece follows on from pipeline security, which covers protecting the process that builds your software. This one is about the thing the process produces, and about being able to prove, at the moment of deployment, that the artefact in front of you is the one your pipeline built from the commit you reviewed.
Two properties of artefacts that controls tend to miss
Opacity. Your direct dependencies are a short list somebody chose deliberately. What actually ships is a tree several layers deeper, assembled by resolvers, containing packages nobody in your organisation has evaluated or heard of. When a serious vulnerability lands in something at depth four, the question is not whether you are exposed but whether you can find out quickly, and most estates answer that with a week of manual work.
Mutability. A build produces an artefact, and that artefact then sits somewhere before it runs. Registry credentials, a compromised publishing token, or a mutable tag are all sufficient to change what deploys without touching the pipeline. The build logs still look correct because the build was correct. The thing that changed happened afterwards.
Those two properties are why inventory and provenance are different controls solving different problems. The SBOM answers what is in it. Provenance answers where it came from. You need both, and you need something that checks them at the point of use.
The technical detail
Make the SBOM queryable, or do not bother
An SBOM is a structured list of components in an artefact, in one of two mainstream formats. Generating one is close to free and every major toolchain will do it. The question that determines whether it was worth doing is where it lands.
The test to apply is simple. When a serious vulnerability is announced, can somebody answer, in minutes and without writing a script, which running services contain the affected package and at which version? If the answer requires opening files by hand, you have inventory theatre. What makes it real is storing SBOMs in something queryable, keyed to the artefact digest, and joined to a record of what is actually deployed. The second half is the part most programmes miss: knowing what is in an image is only useful alongside knowing where that image runs.
Sign the artefact, and separate the attestation from the thing it describes
Signing gives an artefact a verifiable origin. Keyless signing approaches, where a short-lived certificate is issued against the workload identity of the build and the signature is recorded in a transparency log, have largely displaced the older model of a long-lived signing key sitting in a secret store, and for good reason: a signing key in a CI secret store has all the problems of any other static credential, with worse consequences.
Provenance goes further than a signature. It is a signed statement describing how the artefact was produced: which source commit, which builder, which parameters. That is what lets you distinguish an image built by your pipeline from an identical-looking image pushed by someone with registry credentials.
One design detail worth insisting on, because it quietly invalidates the control when it is wrong: the attestation should be produced by something with a different trust boundary from the step being attested. If the build job generates its own provenance and signs it with its own identity, then anything that compromises the build can produce convincing provenance for a malicious artefact. Provenance generated by the platform, rather than by the job, is the meaningful version.
Verification, which is where it becomes a control
Everything above is preparation. The control is a policy at the deployment boundary that refuses artefacts it cannot verify: signature present and valid, provenance matching an expected builder and source repository, image referenced by digest rather than tag, and registry on an allow-list.
In Kubernetes that is an admission controller. In a managed platform it may be a deployment policy or a pipeline gate. The mechanism matters less than the enforcement mode, and this is the single most common failure in the whole area: the policy is deployed in audit mode so it does not break anything, everyone agrees to switch it to enforcing after the next release, and eighteen months later it is still logging violations that nobody reads.
Reproducibility and hermetic builds, briefly
Full build reproducibility is a significant engineering investment and is not where most organisations should start. The intermediate step that delivers most of the value is a hermetic build: dependencies resolved from a lock file, pulled from an internal proxy or mirror rather than the public internet at build time, and base images referenced by digest. That removes the class of problem where the same commit produces a different artefact tomorrow because something upstream moved.
| Step | Artefact produced | Failure if skipped |
|---|---|---|
| Hermetic build | Lock files, mirrored dependencies, digest-pinned bases | Same commit, different output |
| Inventory | SBOM per artefact, stored and queryable | Days to answer a CVE question |
| Signing | Signature bound to build identity | No way to distinguish your image from theirs |
| Provenance | Signed build metadata from the platform | Signature proves who, not how |
| Verification | Enforcing admission policy | Everything above becomes documentation |
Delivering it: who, what, when, deliverables, lineage
Who. Platform engineering owns the build and the deployment boundary; security owns the policy and the exception process. The failure mode here is a security team mandating signing without owning the verification path, which produces signatures nobody checks.
What. Start with the deployment inventory rather than the SBOM. You cannot enforce a policy at a boundary you have not enumerated, and the exercise of listing every path by which code reaches production usually finds two or three nobody remembered.
When. Inventory, then signing, then provenance, then enforcement, in that order, with enforcement piloted on one non-critical service before it goes estate-wide. Set the date for moving from audit to enforcing at the start, and treat slipping it as a decision requiring a reason, not a default.
Deliverables. A deployment path inventory, an SBOM store keyed by artefact digest, signing integrated into the build, an admission policy with a documented exception process, and a vulnerability response runbook that uses the inventory. The runbook is what proves the programme worked, because it converts the whole investment into a measurable response time.
Lineage. This descends directly from pipeline security. Signing and provenance are only as trustworthy as the pipeline producing them, so a supply chain programme that starts here without hardening the build first is building on an assumption it has not tested. It also connects upward to procurement and assurance, since customers and regulators are increasingly asking for exactly the artefacts this work produces.
The honest summary
Supply chain security has an unusual failure pattern: organisations do most of the work and then skip the last step, because the last step is the only one that can say no. Generating SBOMs and signatures is invisible and safe. Refusing to deploy something is neither, and it is the point.
If you want a single diagnostic, take the most recent serious vulnerability in a widely used library and time how long it takes to produce a list of affected services. That number is your actual supply chain posture, and it is considerably more informative than whether a tool is enabled.
If you want help getting from generating attestations to actually enforcing them, that is the kind of work I do through Cyber Spartans.