An SBOM lists the components inside a single piece of software. A software inventory lists the products, services, repositories and systems a company owns or runs. Acquirers usually want both: the inventory shows what exists, and an SBOM for each item shows what it is made of.
Definitions
NTIA describes a software bill of materials as a nested inventory for software, a list of the ingredients that make up software components. The scope is one product or one build.
A software inventory sits a level above. It answers "what do you have?" in terms of applications, services, mobile apps, internal tools, third party SaaS and the repositories behind them. It rarely lists individual libraries.
| SBOM | Software inventory | |
|---|---|---|
| Question answered | What is inside this product? | What products and systems exist? |
| Typical rows | Packages, versions, licenses | Apps, services, repos, owners |
| Changes | Every release | When products are added or retired |
| Main reader | Security and legal reviewers | Deal team and technical leads |
Why acquirers need both
An SBOM for one product is useless if the buyer does not know whether it is the main product or a side project. An inventory with no SBOMs tells the buyer what you own but nothing about the risk inside it.
The common failure is an SBOM for the flagship application and silence about the rest: the admin tool, the data pipeline, the old mobile app, the internal scripts with production credentials. Buyers discover those later, and the question becomes what else was missed.
Building the inventory in an afternoon
- List every repository in your source control organisation, including archived ones.
- Group repositories into products or services. Note what each does in one line.
- For each, add an owner, a deployment status (live, internal, retired) and the main language.
- Mark which items ship to customers and which run inside the company alone.
- Add third party services that process customer data, linked to the subprocessor list if you have one.
- Link each live product to its latest SBOM and the date it was generated.
A spreadsheet is fine. A source of truth that someone updates when a repository is created is better.
Where gaps hide
Repositories created by contractors, forks used for experiments, and services deployed from a developer's laptop long ago. Compare the repository list to your cloud account and your container registry. Items present in the runtime but missing from the inventory are the ones to chase first.
What to write in the data room
Two files, linked. The inventory with a "last updated" date, and a folder of SBOMs named by product and release. Add a short note on what is out of scope and why, for example retired projects with no production traffic.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how one product's component list is a different view from a list of all your projects.
Safeguard includes asset discovery, which helps find repositories and systems missing from a list, plus SBOM generation for each. A free scan is a quick way to see one product's output.
Quick check
Can one SBOM cover the whole company?
Technically you can merge them, but a buyer usually wants one per product or release so findings map to something specific.
Do retired products belong in the inventory?
List them with a retired status and the date. Say whether anything still runs or holds data.
Sources
Last reviewed: 19 October 2026.
