Your SBOM Is a Shopping List, Not a Safety Certificate

Somewhere in the last eighteen months the software bill of materials stopped being a security-team artefact and became a line item on the procurement form. Which is fine. Progress, even. Except that most of the people now requesting one have never read one, and most of the people supplying one are hoping that remains the case.

So let us be plain about it, because this is not a topic that rewards mystique.

What an SBOM actually proves

An SBOM is a machine-readable list of the components inside a piece of software — libraries, versions, sometimes licences and hashes — typically in SPDX or CycloneDX format. It answers one question: does the supplier know what is in the thing they are shipping you, and can they tell you in a format a tool can digest?

That is a genuinely useful thing to know. A supplier who can produce a current, component-level list on request has some handle on their own supply chain. A supplier who cannot is telling you something too.

But note the limits. It is a receipt for the contents. It is not a warranty that the contents are safe, and it is certainly not evidence that anyone has looked at them since.

What it quietly does not prove

A pile of SBOMs can create a confidence that the paperwork does not support. Specifically, an SBOM does not tell you:

• whether the listed versions match the build you are actually running;
• how deep the transitive dependencies go, or whether the list stops at the libs the developer typed out themselves;
• whether any of those components have known vulnerabilities this week;
• whether a flagged vulnerability is exploitable in your configuration (that is a separate document — more below);
• whether the build was clean, or whether someone could have slipped something in before packaging.

Freshness matters more than completeness here. A beautifully formatted SBOM from fourteen months ago is archaeology.

Signing makes a different claim entirely

Code signing gets bundled into the same conversation, which is a shame, because it answers a different question. A valid signature tells you the artefact came from whoever holds that key and has not been altered since it was signed. It says nothing about what is inside.

Provenance attestations — the sort of thing SLSA and in-toto describe — get you closer, because they say something about how and where the build happened. Useful. Still not a guarantee of quality.

And VEX, briefly: a Vulnerability Exploitability eXchange statement is a supplier saying “this known flaw in this component does not affect our product, and here is why”. Extremely useful when written carefully, and occasionally wishful when written quickly. Treat a VEX claim as an assertion to be trusted in proportion to how much you trust the supplier, not as a fact.

How to ask without sounding like an auditor

Short email, six lines, sent to your account manager and cc'd to support:

“Hello — as part of our annual supplier review, could you send the current machine-readable SBOM for [product] in CycloneDX or SPDX JSON, plus the two previous versions with dates? Could you also point us at the cadence for refresh, your process for notifying customers about critical vulnerabilities in third-party components, and any verification instructions for your signed releases? Happy to take a call if easier.”

That is it. No framework name-dropping, no threats. Suppliers who have their house in order will answer in a day. Suppliers who do not will send a marketing PDF about their “security-first culture”, which is your answer.

The 2026 starter: one supplier, one afternoon

Do not try to inventory the estate. Pick the one supplier whose outage would ruin your month and work through this:

1. Request the SBOM in a machine-readable format, not a screenshot and not a spreadsheet of top-level libraries only.
2. Check it is dated and versioned, and that it names versions for transitive dependencies.
3. Ask when it is regenerated — per release, monthly, on request?
4. Ask how and how quickly they will tell you about a critical CVE in a component they use.
5. Ask for the VEX or advisory covering the last notable CVE in their stack, and read the reasoning.
6. Ask whether the SBOM covers the hosted service you use, or only the agent you install on your laptops. The gap is usually enormous.
7. Ask for a signed release and try verifying one download yourself. Ten minutes, and surprisingly revealing.
8. Note who at your end owns the answer, and where the file lives.
9. Write down what you would actually do if a log4j-style event happened tomorrow. If the answer is “wait for an email”, you have found the real gap.

Nine questions, one supplier, one afternoon. That is a better use of time than a folder of unread PDFs from forty vendors.

Procurement theatre is still progress

There is a fair amount of box-ticking in all this. Cyber Essentials does not require an SBOM. The EU Cyber Resilience Act's reporting duties start to bite from September 2026, which means plenty of suppliers are building the capability now regardless of whether UK buyers ask. That is quietly good news: the question is becoming cheaper to ask.

But a compliance pack assembled to satisfy a form is not the same as a supplier who can tell you what happens when a widely used library falls over on a Friday afternoon. The document is a means. The conversation is the point.

The honest position

You do not need a security department to do this. You need one supplier, one afternoon, and a written answer to a single question: when the next component disaster lands, how will we hear about it, and what will we do next?

Everything else — the formats, the signatures, the attestations — is scaffolding around that. Useful scaffolding. But if you collect the paperwork without ever asking the question, you have not improved your security posture. You have built a very tidy filing cabinet.