Binary SBOM verification

An SBOM is a claim about a binary. We check it against the binary.

You require SBOMs from your suppliers. They send them. The documents are well-formed, they parse, they go into a register, and the control is satisfied.

Nothing in that process establishes that the SBOM describes the artifact sitting next to it.

An SBOM is emitted by the supplier's build system, from the supplier's understanding of their own dependencies, and handed to you as an assertion. It is a self-attestation. You would not accept a supplier's own word that their software is free of vulnerabilities — an unverified SBOM is exactly that, in list form.

There is only one document that cannot be wrong about what shipped, and it is the shipped binary.

Why this has to happen at the binary level

The obvious alternatives all fail for the same reason.

Reading the SBOM compares a document against itself. It can catch a malformed record; it cannot catch a missing one.

Source or repository scanning — where a supplier even grants it — re-derives the SBOM from the same build-time view that produced the original. If the manifest was blind to a statically-linked library, a scan of the same tree is blind to it too. You get the supplier's answer a second time, with more confidence and no more truth.

Composition-analysis tooling run over the artifact will find the easy cases: unstripped metadata, embedded version strings, recognisable package layouts. It goes quiet exactly where the risk concentrates — stripped code, statically-linked components, vendored source with the identifying strings compiled away.

The binary is also the one artifact you are guaranteed to possess. You may not get source. You will not get their build system. You already have the thing you are going to run.

The two failure directions are not equally dangerous

This is the distinction that decides what an SBOM is worth to you.

Listed but absent — the SBOM names a component the binary does not contain. Untidy. It inflates your exposure on paper and wastes triage effort, but it does not hurt you.

Present but unlisted — the binary contains a component the SBOM never mentions. That is code you do not know you are running, so it is:

• outside every vulnerability scan you perform, because you scan the list
• outside your licence-compliance position, with whatever obligations it carries
• outside your incident response — when that component takes a critical advisory, nothing in your tooling will tell you that you are affected

Only the binary can reveal an omission. A document cannot report what it fails to mention. That asymmetry is the whole argument for verifying rather than filing.

What we work from

Shipped artifacts, in the form you received them:

• firmware images, including packed, nested and proprietary container formats
• executables and shared libraries, stripped or not
• container images and their layers
• update and installer packages

No source required. No supplier cooperation required.

What you get

• A conformance report, component by component, with three verdicts: confirmed present in the binary, listed but not found, and found in the binary but not listed.
• Version accuracy from the binary, not from a version string a build system wrote down. A single version of drift is frequently the difference between patched and exploitable.
• The unlisted-component inventory — the highest-value output. What is in the artifact that your supplier did not tell you about, each with a confidence level.
• Vulnerability exposure recalculated against what is actually present, with reachability assessed rather than assumed — a vulnerable component whose affected code is not callable in this build is a different problem from one that is.
• Integrity and provenance checks where signatures or attestations exist: does the artifact you received match what was signed.
• A coverage ledger — what we examined, what we identified, and what we could not attribute.

Output in CycloneDX or SPDX plus a written report, so it drops into whatever you already use to track supplier risk.

How we take the binary apart

• Extraction and unpacking of firmware images, nested archives, and proprietary containers
• Component identification by binary fingerprinting, string and constant analysis, code-pattern matching, and structural comparison against known builds
• Version discrimination on stripped binaries — identifying which release you have from the compiled differences between candidate versions, when the metadata that would have told you was removed at build time
• Static-linking and vendoring detection, where a component has no package boundary left to find
• Reachability analysis into the affected code paths of components that matter
• Reconciliation against the supplied SBOM to produce the conformance report

On the limits, stated up front

Binary component identification is inference. Some components identify with certainty. Some identify to a version range. Some regions of a stripped, optimised binary cannot be attributed at all. Each is reported with its confidence, and unidentified regions are reported as unidentified.

A report claiming complete coverage of a stripped binary is telling you something false. Be suspicious of any vendor whose output contains no unknowns — including us, if we ever hand you one.

Where this fits in your process

Pre-procurement gate. Verify one representative binary before you take a dependency on a supplier. Cheapest possible moment to discover their SBOM practice is decorative.

Release acceptance. Verify each delivered build against the SBOM that accompanies it. After the first pass this becomes drift tracking rather than a fresh assessment.

Incident response. A critical advisory lands. Your register says you are unaffected. Verification tells you whether that is true of the binaries you actually deployed.

Regulatory evidence. The Cyber Resilience Act and comparable regimes put obligations on manufacturers, but the operator carries the operational risk. Independent binary verification is evidence you did more than collect a document.

Also: deriving your own

The same capability points the other way. If you are the one shipping software, your build-time SBOM describes what your build system knew about — not what your artifact contains. Statically-linked libraries, source vendored in years ago, code compiled from a submodule, anything added outside the package manager: none of it appears in the manifest, and all of it is in what your customers receive.

We derive the SBOM from your artifact and give you the gap report against your build-time one, before a customer or an assessor does it for you.

Engagement shapes

Shape	Fits	Typical duration
Single-artifact verification	One supplier binary against its SBOM	1–2 weeks
Supplier assessment	Several artifacts from one vendor, or a release history	2–4 weeks
Acceptance retainer	Each delivered release verified, drift tracked	ongoing
Own-artifact SBOM	You are the supplier; derive and gap-report your own	1–3 weeks

Scoped per engagement — cost depends on artifact size, packing, and how much is stripped. We quote fixed after looking at one representative binary under NDA.

Questions we get asked

Our suppliers are large vendors. Surely their SBOMs are accurate? Size correlates with process maturity, not with binary accuracy. Large vendors carry more acquired codebases, more legacy static linking, and more build systems that predate their SBOM tooling. The gaps are not smaller — they are just documented better somewhere else.

Can we not run a composition scanner over the binary ourselves? You can, and you should — it finds the easy cases. What it will not give you is version discrimination on stripped code, an honest confidence level per identification, or a judgement about whether a vulnerable component is reachable in this build. Those are the parts that change decisions, and they are the parts that need a person.

What if the supplier disputes the findings? Good — that is the conversation worth having, and the reports are built for it. Each identification carries its evidence and confidence, so the discussion is about a specific artifact rather than competing assertions.

Do we need the supplier's cooperation? No. We work from the binary you already have. Cooperation helps resolve ambiguous identifications, but verification does not depend on it — which is rather the point.

We have hundreds of suppliers. Start with the ones whose software runs somewhere consequential, one artifact each. That is usually enough to tell you which suppliers need a real programme and which are fine.