SBOMs in M&A due diligence: reading a target's supply chain

Technical due diligence used to mean a code walkthrough and an architecture deck. Increasingly it means a much blunter request, delivered by the acquirer's counsel alongside the financial data room checklist: provide a software bill of materials for every product.

The request makes sense from the buyer's side. An acquisition is the wholesale purchase of someone else's technical decisions, and the SBOM is the most honest inventory of those decisions that exists. It cannot be polished the way a slide deck can.

What an acquirer reads in your SBOM

A diligence team with an SBOM in hand is answering four questions:

1. License risk. Are there copyleft components in proprietary products? A GPL-licensed library in the core product is a deal-structure conversation; a forgotten AGPL dependency in a SaaS backend is a remediation cost that lands directly on the purchase price.
2. Vulnerability posture. Not "are there CVEs" — there are always CVEs — but what the pattern says. A tail of years-old critical vulnerabilities in shipped products says the maintenance process, not the codebase, is the problem you're buying.
3. Dependency health. Components pinned five majors behind, abandoned upstream projects, a single maintainer between a core dependency and the void. This is deferred cost, and diligence teams price it.
4. Operational maturity. Can the target produce a current, complete SBOM at all — in days rather than weeks? A company that generates SBOMs from its build pipeline demonstrably has a build pipeline worth acquiring.

For sellers: the asymmetry is the point

Here is the uncomfortable dynamic: if you cannot produce the inventory, the acquirer will generate one themselves from your artifacts — and then the only narrative attached to your dependency posture is the one their analysts write. Producing your own SBOM, with your own VEX statements explaining which findings are actually exploitable and your own remediation history attached, means the diligence conversation happens on your terms.

The preparation is the same posture that serves compliance and customer trust:

• Generate SBOMs continuously from the build, so "current" is always true
• Keep vulnerability triage decisions recorded next to the inventory, so every open finding has a story
• Track license obligations before someone else's counsel does
• Be able to share all of it selectively, under access control, with an audit trail of who saw what

The quiet trend

None of this is written into a regulation. It is simply what technical diligence now looks like at acquirers who have been burned. Like security questionnaires before it, the SBOM request in the data room has moved from unusual to standard in a few short years — and the companies that treat their SBOM as a living asset rather than a fire-drill deliverable walk into that conversation with nothing to scramble for.