In an acquisition, an SBOM lets the buyer see what third party code the target ships, which licenses apply and which components have known vulnerabilities. Produce one per product from the released build, in SPDX or CycloneDX, and be ready to explain every unknown or outdated entry.
Why buyers want it
CISA calls an SBOM a key building block in software security and software supply chain risk management. In diligence it replaces a long interview with something checkable. The buyer can match components against vulnerability and license data on their own.
Formats
SPDX is an open standard hosted by the Linux Foundation, recognised as ISO/IEC 5962:2021. CycloneDX is the other common format. Either is fine. Offer what your tooling produces natively and avoid hand conversion, which loses fields.
Generate from the build, not the repository
A manifest scan shows what you declared. A build scan shows what shipped, including transitive packages and container layers. Buyers know the difference. Generate from the released artifact where you can, and label how each file was made.
What buyers do with it
- Check licenses against their own policy and the deal terms.
- Look up known vulnerabilities and compare them with your remediation log.
- Look for abandoned or unmaintained packages.
- Check whether components appear that you did not mention.
Prepare your explanations
Expect questions on:
- Packages with no license field.
- Components several major versions behind.
- Anything flagged as exploited in the wild.
- Forked or vendored code with no upstream record.
Write a short note per item. "Used only in test tooling, not shipped" is a useful answer if it is true and you can show it.
Keep it current
An SBOM from last year invites doubt. Regenerate on each release and keep the history. Reachability analysis helps separate vulnerabilities in code you actually call from those that sit unused.
Safeguard offers SBOM and dependency scanning plus reachability analysis. A free scan is at https://gold.safeguard.sh/scan.
Mistakes that cost time
Three mistakes show up repeatedly. First, sending one SBOM for the whole company when buyers want one per product and version. Second, sending a file with no timestamp or tool name, so nobody knows how fresh or complete it is. Third, leaving out container base images and build tooling, which then appear in the buyer's own scan and look like omissions.
Include a short cover note with each file: tool used, date generated, build or commit identifier, and known limits. If a tool could not resolve a package, say so. Buyers forgive limits that are stated and distrust ones they discover.
Also keep the vulnerability view separate from the inventory. The SBOM lists components. Findings change daily, so attach them as a dated report.
Quick check
Is an SBOM enough for security diligence?
No. It covers components only. Buyers still ask about access, incidents, data and compliance.
Sources
Last reviewed: 19 October 2026.
