Why SBOMs Diverge From the Binary You Actually Ship

The SBOM your vendor emailed you was generated from their source repo at build-time on a Tuesday in March. The binary they shipped you in October contains seventeen components that document never mentions. This is not an edge case. This is the default.

A Binautopsy review of a recent enterprise networking appliance found 41% of the components present in the firmware image had no entry in the vendor-supplied CycloneDX file. Some were statically linked dependencies-of-dependencies. Some were vendored copies of OpenSSL the build engineer forgot existed. One was a 2019 fork of zlib with a known heap overflow.

If your third-party risk program treats source SBOMs as evidence, you are auditing a document. Not a product.

Where the Drift Comes From

Source SBOMs describe intent. Binary SBOMs describe reality. The gap between them is paved with:

• Static linking. A dependency compiled directly into the executable leaves no package manifest behind. Source-side tools miss it entirely unless someone hand-curated the manifest.
• Vendored code. Engineers copy a library into the repo, modify it, forget to update version metadata, and ship a Frankenstein no scanner recognizes.
• Build-time injection. CI pipelines pull base images, sidecar agents, and telemetry libraries that never appear in the application’s package.json or pom.xml.
• Stripped symbols and obfuscation. Even honest vendors strip binaries for size or IP reasons, which silently erases evidence of what was linked.
• Firmware blobs inside firmware. A router image often contains an entire secondary OS image, with its own kernel, busybox, and OpenSSL — none of which appear in the parent SBOM.

None of this is malicious. It is what shipping software looks like when the SBOM is generated by a tool that never opens the artifact.

What a Binary-Derived SBOM Actually Proves

A binary SBOM is produced by dissecting the artifact you are about to deploy. Not the source. Not the build plan. The bytes.

That changes what the document means. A source SBOM says we believe these components are present. A binary SBOM says these components are present, here are their versions, here are the file offsets, here is the cryptographic hash of each one. One is a claim. The other is evidence.

For regulated buyers — banks, healthcare systems, federal contractors — that distinction is the difference between a checkbox and a defensible verdict. Regulators under CRA and EO 14028 are increasingly explicit that attestations must be verifiable. A vendor’s signed CycloneDX file is not verifiable on its own. A binary-derived SBOM, hash-anchored to the artifact in your procurement queue, is.

What This Means for Procurement Gates

When a vendor hands you an SBOM during contract negotiation, the right question is not did they provide one. The right question is was this generated from the binary I am about to receive, or from a tree of source files I will never see.

If the answer is the latter — and it almost always is — the document tells you what the vendor’s build engineer believed in March. It does not tell you what is in the appliance arriving at your loading dock.

This is the gap the Pre-Procurement Binary Autopsy is built to close. Two weeks. The actual artifact. A verifiable SBOM derived from the binary, exploitability-ranked findings, license exposure mapped against the components the vendor’s document missed, and a one-page signed verdict your CISO and procurement team can defend.

The Uncomfortable Implication

If you have been relying on vendor-supplied SBOMs as evidence of due diligence, your file cabinet is full of paperwork describing software you have never actually inspected. That is a defensible position only until something in one of those binaries shows up on a CISA advisory and your board asks what you knew and when.

The SBOM is not the artifact. The binary is. Treat them accordingly.

Binautopsy dissects the artifact you are about to buy and returns a verdict before the contract is signed. If your procurement gate is closing this quarter and the vendor’s documentation is the only thing standing between you and deployment, that is the moment a binary autopsy is for.