A data room for open source should hold five things: a dated component inventory per product, evidence of how it was produced, license records, vulnerability and exception records, and a list of who owns each repository. Together they let a buyer check the inventory instead of trusting it.
Why an index beats a dump
Sellers often upload one SBOM file and consider the topic closed. Buyers then spend weeks asking follow up questions. A short index that anticipates those questions saves time on both sides.
The NTIA minimum elements report lists seven baseline data fields for an SBOM: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. Use those as the floor for the inventory file itself. Everything else in the room exists to show the file is complete and current.
The five folders
| Folder | What goes in it | Question it answers |
|---|---|---|
| 1. Inventory | One SBOM per product and release line, in CycloneDX or SPDX, with the seven baseline fields | What open source do you ship or run? |
| 2. Provenance of the inventory | Which tool, which repo and commit, which build, when | Can we trust the file? |
| 3. Licenses | License per component, list of unknown or custom licenses, notes on how code is distributed | What terms apply? |
| 4. Vulnerabilities | Current scan results, accepted risks with owner and expiry, VEX statements if used | What is known and what is decided? |
| 5. Ownership | Repository list with owner, language, deployed or not | Who answers questions? |
What makes each folder useful
Inventory. Include transitive dependencies, not only the direct list. The NTIA report says an SBOM should list all top level components with their transitive dependencies, and that where the graph is incomplete the author must mark the gaps as known unknowns. Ask the seller to mark them.
Provenance. A timestamp and the commit hash tie the file to a specific state of the code. Without them an inventory is a claim with no date.
Licenses. Record the license identifier per component. Where the field is NOASSERTION, the SPDX specification says that can mean the creator could not determine it or made no attempt. Treat it as an open item, not as a clean result. This is a data question for your counsel to interpret, not a legal conclusion.
Vulnerabilities. A scan result without exceptions is rare. A scan result with owned, dated exceptions is a better sign than a suspiciously empty one.
Ownership. Name a person per repository. Orphaned repositories are where surprises live.
What to leave out
Do not put source code, secrets or customer data in this folder. Share the inventory and the evidence about it, and move deeper code review to a controlled session if the deal advances.
A short seller checklist
- One inventory per shipped or hosted product, not one for the company.
- A date on every file.
- A note on what the inventory does not cover.
- Exceptions listed with reasons.
- A named contact for follow up.
Safeguard can generate SBOMs and run dependency scanning across repositories, and asset discovery helps find repositories nobody listed. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is one SBOM per company enough?
Usually not. Inventories describe a specific product and version. Provide one per product and release line so the buyer can map findings to what is actually sold or run.
Should the seller redact anything?
Internal package names and repository paths can be redacted if the buyer agrees on how to map them back later. Do not strip versions, identifiers or the timestamp, because they carry the value.
Sources
Last reviewed: 19 October 2026.
