Before you send a buyer an SBOM, agree five things: the file format, which product and version it covers, how often you will refresh it, how it will be kept confidential, and how findings from it will be raised. Settling these avoids a stream of unplanned requests after the first file.
Why agree first
An SBOM is a detailed inventory of what is inside your software. CISA describes SBOMs as an ingredients list that helps organizations understand the makeup of their software and make risk informed decisions. For a buyer, that is useful. For you, it reveals your stack, and a careless handover can lead to endless follow-up questions about every line.
CISA published its 2026 minimum elements for an SBOM on 29 July 2026, replacing the 2021 NTIA baseline. The page also notes that some software types, including software as a service in cloud environments, may need additional elements. So ask the buyer which baseline they expect.
The five points
| Point | Questions to settle |
|---|---|
| Format | Which standard, such as SPDX or CycloneDX, and which version? |
| Scope | Which product, which release, application only or including container images? |
| Cadence | Per release, quarterly, or on request only? |
| Confidentiality | Under NDA? Who may see it? Will it be shared with third parties? |
| Follow up | Where do findings go, and what response time is reasonable? |
SPDX describes itself as an open standard for communicating bill of materials information, so it is a safe default if the buyer has no preference. Offer to provide either common format if your tooling supports both.
Scope pitfalls for SaaS
For a hosted service, the buyer is not running your code, so ask why they want the SBOM. Common reasons are advisory checks ("are you affected by this CVE") and diligence. If the reason is advisory checks, a per release SBOM plus a promise to answer advisory questions may be enough, without sending a file every month.
Decide whether to include:
- Direct and transitive application dependencies.
- Container base image packages.
- Build tools that do not ship.
- Internal packages, which may reveal naming and structure.
Handle the findings conversation
Buyers sometimes run the SBOM through their own tools and send you a list of vulnerabilities. Agree that you will respond with a triage, not necessarily a fix for each item. Many findings will be unreachable or already addressed. A short note on exploitability, such as a VEX statement, helps. See SBOM versus VEX for when to add it.
Keep your side tidy
- Generate the SBOM from the pipeline, not by hand.
- Name files by product, version and date.
- Keep a log of who received which file.
- Redact internal package names if policy allows.
Whether a contract clause is appropriate is a matter for the deal owner and counsel. Your job is to supply the facts about what you can deliver.
Try it yourself
Click through it at your own pace, or open it full screen. See what an inventory contains, and decide which of those fields you would be comfortable sharing.
Safeguard generates SBOMs and dependency inventories, and you can try the free scan to produce a first one.
Quick check
Should the first SBOM go out before an NDA?
Usually safer after. Confirm with your own policy and the deal owner.
Do I owe a new SBOM every time a dependency changes?
Only if you agreed to. A per release cadence is a common starting point.
Sources
Last reviewed: 19 October 2026.
