Photo by Tasha Kostyuk on Unsplash. Source: https://unsplash.com/photos/a-man-sitting-in-front-of-multiple-monitors-TtMKq3lJm-U (Unsplash License).

Executive Summary

A component list tells an auditor what you shipped. It says nothing about who built it. Supply chain reviews have moved past inventory and now ask for proof of origin. That shift is stalling enterprise renewals that used to clear on licensing alone.

In the SolarWinds breach every listed component was legitimate, because the attacker changed the build pipeline instead. SLSA grades build trust, and its top level expects an isolated builder that keeps signing keys away from the code it compiles. SLSA is an OpenSSF project, not a CNCF one. Sigstore made signing practical by removing the long-lived key. Fulcio issues a short-lived certificate, and Rekor records the event in a public transparency log. A verifier checks that entry without your private key and without a support ticket. The attestation format it signs comes from in-toto, a CNCF Graduated project. Procurement asks four things. Signed artifact, provenance, independent verification, and a pipeline that refuses to ship an unsigned build. Watch registry push rights. If anyone with a token can publish, the signature proves a build happened, not that the right one shipped.

Most teams treat an SBOM as the finish line of a software supply chain audit. It is not. A component list tells an auditor what you shipped. It says nothing about how you built it, or whether someone swapped the binary after the build.

That gap is where the real review happens now. Procurement teams and outside assessors have learned that a dependency list is easy to generate and easy to leave stale. They want proof of origin instead. More enterprise renewals stall on that question than on licensing.

An SBOM Is an Inventory, Not a Record of Origin

A bill of materials answers exactly one question. What is inside this artifact? Open formats such as SPDX do that work well, and the tooling to emit them is now close to free. Regulators pushed bills of materials into the mainstream, and most build systems can produce one on every commit.

But an inventory has a blind spot. It cannot tell you who ran the build or which source commit went in. In the SolarWinds breach, every listed component was legitimate. The attacker had changed the build pipeline itself. A clean bill of materials would have raised no alarm at all.

That is the problem SLSA was built to close. The framework grades how much a build can be trusted. It asks whether provenance exists, whether it is signed by the builder, and whether a tenant could forge it. The top level expects an isolated builder that keeps its signing keys away from the code it compiles.

One naming detail trips up supply chain reviews every week. SLSA is an OpenSSF project, not a CNCF one. Say that plainly, because a sloppy label invites follow-up questions you cannot answer.

The two artifacts also answer different threats. A bill of materials helps you react after a vulnerable library makes the news. Provenance helps you before the fact, by proving the code in production is the code your pipeline built.

Auditors Want a Signature They Can Check Without Calling You

A signature turns a claim into evidence. Sigstore made signing practical by removing the long-lived key that teams never rotated. The Cosign client signs an artifact, Fulcio issues a short-lived certificate tied to a real identity, and Rekor records the event in a public transparency log.

That log is the part auditors care about. A verifier confirms a signature without holding your private key and without a phone call. They check the entry, confirm the identity, and move on. The evidence stands on its own.

A build attestation is just a signed file. It records what was built, from which source, by which builder, and under what settings. Customers compare that record against the digest they actually pulled. Your CI platform can emit one on every release.

Here is the maturity point to get right. Sigstore is an OpenSSF project, so it carries no CNCF maturity level at all. The attestation format it signs comes from in-toto, which is a CNCF Graduated project. State the tier for the project that actually holds one.

What the Questionnaire Actually Asks

Procurement teams tend to ask the same four questions. Does a signed artifact exist? Does a provenance record exist? Can a customer verify both without your help? Does your pipeline refuse to ship an unsigned build? If you cannot answer all four with a link, the review is not finished.

The most useful move is to publish the evidence next to the artifact. Attach the bill of materials, the signature, and the provenance to the image in the registry. A customer then pulls one digest and checks everything in a single step. No email thread required.

One more item shows up on every serious checklist. Who can push to the registry? If the answer is anyone with a token, your signatures prove the artifact was built, not that the right artifact shipped.

One warning about signed supply chain tooling. Two vendors can both ship a compliant build and still leave you unable to verify it. Ask for the exact command before you sign, because a signature you cannot check is not evidence.

A lone bill of materials is table stakes now. Provenance is the part that still separates teams. Wire it into the pipeline once, and the next software supply chain audit costs you an afternoon instead of a quarter.

Supply chain accountability runs through this. The 2026 State of Enterprise Infrastructure report covers what organisations are actually absorbing and which tooling holds up.

Related reading. Root on One Kubernetes Node Is Every Identity on It. Cloud Native Transformation Is an Operating Model Change, Not a Lift and Shift. The Most-Used Storage on Kubernetes Is the One You Get for Free. The 2026 State of Enterprise Infrastructure.

By Ivan Tarin

Ivan Tarin is a Principal Product Marketing Manager at SUSE, where he owns go-to-market strategy and positioning for a seven-product cloud-native portfolio spanning Kubernetes, virtualization, storage, security, and observability. A former full-stack developer who shipped production code for enterprise and public-sector clients including U.S. national laboratories, Ivan translates complex infrastructure and AI technology into messaging that lands with developers, platform teams, and enterprise buyers. He has presented at KubeCon, SUSECON, and AWS Developer Week, and is currently pursuing an MS in Artificial Intelligence at the University of Colorado Boulder.

5 thoughts on “A Software Supply Chain Audit Wants Proof, Not a Longer SBOM”

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the next one before it is old news

Independent analysis of cloud-native infrastructure, Kubernetes and data centre economics. No vendor spin.