Describe where the inventory lives, how it is generated, how often it refreshes and who uses it. "We generate a machine-readable inventory from the build for every release, and we match it against vulnerability data" is stronger than "we track our libraries."
What an inventory has to cover
A usable inventory lists direct dependencies and transitive ones, with names and versions, for each shipped artifact. CISA describes a software bill of materials as a nested inventory, a list of the ingredients that make up software components. Its 2025 minimum elements guidance builds on the earlier NTIA baseline and adds data fields and practices.
Two common formats are SPDX and CycloneDX. SPDX describes itself as an open standard for communicating bill of materials information, including provenance, license and security data, and it was published as ISO/IEC 5962 in 2021.
The four facts a customer wants
- Source of truth. Generated from the build or lockfile, not from memory or a spreadsheet.
- Coverage. Application dependencies, container layers and, where relevant, build tooling.
- Freshness. Rebuilt on each release, or on a stated schedule.
- Use. Matched against advisories and license rules, with an owner.
Strong and weak answers
| Weak | Stronger |
|---|---|
| "We keep a list of libraries." | "A CycloneDX file is generated in CI for each release." |
| "Engineers know what they use." | "Direct and transitive components are listed with versions." |
| "We scan sometimes." | "The inventory is checked against public advisory data on a schedule." |
| "It is in a spreadsheet." | "It is stored with the release record and versioned." |
Swap in your real format and cadence. If your list is incomplete for older products, say which ones.
Common gaps to disclose honestly
- Vendored or copied code that no lockfile records.
- Container base image packages.
- Front end bundles built from a different manifest than the back end.
- Components added by build scripts at runtime.
Mentioning a known gap and a plan is better received than a clean claim that an audit later contradicts.
Checking your own answer
Before sending the reply, test it. Pick one release and generate the inventory. Count the direct and transitive components, confirm the license field is filled in and compare the list to the container image contents. If the numbers surprise you, the customer's scanner will be surprised too. Fixing the surprise first is cheaper than explaining it afterward.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a component in the demo and look for version, license and advisory data together. That joined view is what a good inventory answer describes.
Safeguard offers SBOM generation, dependency scanning and asset discovery. The free scan at gold.safeguard.sh/scan shows the output for a project of your own.
Quick check
Is an SBOM the same thing as an inventory?
An SBOM is a formal, shareable inventory in a standard format. An internal inventory can be broader, but an SBOM is what you send out.
Do we need to list transitive dependencies?
Yes, if you can. Most vulnerable code reaches an application through packages nobody chose directly.
Sources
- CISA, Software Bill of Materials
- CISA, 2025 Minimum Elements for a Software Bill of Materials
- SPDX overview
- CycloneDX specification overview
Last reviewed: 19 October 2026.
