Ask the demo to export a software bill of materials for your repository, then open the file in a plain text editor. Check the format, whether the component count matches your own dependency tree, whether versions are exact, and whether another tool can read it.
What an SBOM is
CISA describes a software bill of materials as a nested inventory, a list of the ingredients that make up software components (see Sources). In practice it is a file that lists packages, their versions and how they relate. Two common formats are CycloneDX and SPDX.
An SBOM is only as good as the data behind it. A tool can export a file that looks right and is missing half the components.
Five checks on the exported file
- Format and version. Which format and which specification version? Ask whether you can choose.
- Component count. Compare it with the dependency tree you pulled from your package manager. A big gap needs an explanation.
- Exact versions. Each component should carry a concrete version, not a range.
- Identifiers. Look for package URLs or similar identifiers. They let other tools match components to advisories reliably.
- Relationships. Does the file show which component depends on which? A flat list loses the path.
Open it yourself
Do not rely on the vendor's viewer. Open the raw file. You do not need to read all of it. Search for three packages you know are in the repo and confirm they appear with the right versions.
Then try loading it into a second, independent tool. If the file only works inside the vendor's product, it is a lock-in risk, not an open inventory.
Questions for the vendor
| Question | Why ask |
|---|---|
| Can I export at any time, without a special plan? | Avoid surprises later |
| Does the export include vulnerability data, or only components? | Different uses |
| Can the SBOM be generated per build, not just per repo? | Releases need their own record |
| Is the export deterministic? | The same input should give the same output |
| Can exploitability status be exchanged? | The CycloneDX specification describes VEX use cases for this |
CycloneDX's overview notes that vulnerabilities and their exploitability can be communicated in the format, which is the basis of VEX (see Sources). Ask whether the tool can produce or consume that data if your customers ask for it.
What to avoid
Do not accept a screenshot as an export. Do not accept "available on request". If an SBOM is a selling point, it should be one click in the demo.
Where Safeguard fits
SBOM and dependency scanning is a GA capability in Safeguard, and the free scan at gold.safeguard.sh/scan lets you see inventory output for a repository of yours. The demo below shows an inventory view.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components and versions are listed, and think about which of these fields you would want in an exported file.
Quick check
CycloneDX or SPDX?
Both are widely used. Ask which your customers or regulators expect, and whether the tool can export both.
Does an SBOM list vulnerabilities?
Not by itself. It lists components. Vulnerability data is matched against it, and can be exchanged separately.
Sources
Last reviewed: 19 October 2026.
