Inside a Pre-Procurement Binary Autopsy: SBOM, Exploitability, License, Verdict

The procurement gate closes in eleven business days. The vendor’s final demo went well. Legal is drafting redlines. Somebody in security needs to sign off that the appliance arriving next quarter does not contain a 2018 OpenSSL or a copyleft license that will detonate the company’s IP posture.

This is the moment a pre-procurement vendor binary review exists for. Not six weeks. Not after deployment. Now.

The Pre-Procurement Binary Autopsy is a two-week forensic dissection of the vendor product or firmware you are about to buy. The deliverable is fixed: a verifiable SBOM, exploitability-ranked findings, license exposure analysis, and a one-page signed verdict. Below is what each of those four pieces actually contains and why each one earns its place in the report.

Verifiable SBOM

The SBOM is derived from the binary, not the vendor’s source tree. Every component listed is anchored to a cryptographic hash of the artifact analyzed and to the file offsets where that component was identified.

This matters for two reasons. First, it is verifiable — a regulator or downstream auditor can re-derive the same SBOM from the same binary and confirm the work. Second, it captures what the vendor’s source-side SBOM misses: statically linked libraries, vendored copies, firmware-within-firmware, and build-injected components no source manifest tracks.

The output format is CycloneDX, suitable for ingestion into existing TPRM tooling, EO 14028 attestation packages, and CRA documentation requirements.

Exploitability-Ranked Findings

A scanner that returns 1,800 CVE matches has not done the work. It has handed the work to the buyer.

The findings section ranks every identified vulnerability against three criteria: whether the vulnerable code path is reachable in the binary as shipped, whether the deployment context exposes it (network-facing vs. internal-only vs. air-gapped), and whether public exploit code exists. The result is a triaged list, typically fewer than thirty findings even on complex firmware, that a CISO can actually act on.

Each finding includes the component, the CVE, the reachability assessment, the deployment-context assessment, and a recommendation: block, mitigate with named compensating control, or accept.

This section is the difference between the binary contains 47 known vulnerabilities and the binary contains three reachable, network-exposed vulnerabilities with public exploits, and forty-four others that do not matter in this deployment.

License Exposure

License findings are produced from the same component identification work as the SBOM. The output flags every component whose license imposes obligations the buyer should know about before signing — copyleft propagation risk, attribution requirements, patent grant exclusions, and field-of-use restrictions.

This section frequently surfaces material the vendor’s commercial team did not know was in the product. That is not an accusation. It is what happens when a build engineer adds a dependency four years ago and nobody re-runs the license audit.

For regulated buyers and any acquirer doing M&A diligence, license exposure on a vendor binary is a liability that transfers with the contract. It belongs in the procurement file.

The One-Page Signed Verdict

The report’s first page is the verdict. Three states: Ship, Ship With Conditions, Do Not Ship.

It is signed by the named analyst who performed the review. It states the verdict, the top three reasons, and — for Ship With Conditions — the specific compensating controls or contract terms required to make the deployment defensible.

This is the page that goes to the CISO, the procurement committee, and, if the deal is large enough, the board. It is built to be defended in a room where someone will ask why this software was approved.

The rest of the report — SBOM, findings, license analysis — is the evidence backing the verdict. The verdict itself is one page because procurement decisions are made on one page.

What the Two Weeks Actually Look Like

Week one: artifact intake, unpacking, component identification, SBOM derivation, initial vulnerability mapping. Week two: exploitability analysis, license review, verdict drafting, partner review, signature, delivery.

No 400-page appendix. No dashboard the buyer has to learn. A defensible answer in the window the procurement gate actually allows.

If there is a contract on the desk and the binary has not been opened, that is the call to make.

Binautopsy uses this perspective to help buyers make a clearer decision.