Test SBOM import by feeding the tool real files from suppliers in both common formats, in more than one version, including a messy one. Check that components are matched to advisories, that missing fields cause a clear warning, and that unmatched components are listed rather than dropped.
Why import matters
Scanning your own repositories is only part of the picture. Customers, regulators and procurement teams increasingly send or request SBOMs, and you may receive them from suppliers whose code you cannot scan. If your tool only generates SBOMs and cannot read them, you will track those components in a spreadsheet.
Prepare test files
Collect a small set:
- One SBOM in each of the two widely used formats, CycloneDX and SPDX
- Two versions of at least one format, since specification versions differ
- One real supplier file if you have it, which is almost always messier than a sample
- One deliberately thin file with only names and no versions or identifiers
Most real files are thin. A tool tested only against a clean sample will disappoint when the first supplier file arrives.
What to check on import
Parsing. Does it accept the file, and does it say clearly when it does not? Silent partial imports are the worst result.
Identification. Components need a stable identifier, typically a package URL or a CPE, to be matched to advisories. See what it does when the identifier is missing: does it guess from the name, ask you, or skip?
Matching quality. Compare findings against a handful you can verify by hand.
Unmatched components. A good tool shows a list of components it could not assess, with the reason. That list is a measure of how much you can trust the rest.
Nested and relationship data. Check whether it keeps dependency relationships when the SBOM includes them, because that determines whether you can see what pulled a package in.
Updates. When a supplier sends a new version of the SBOM, can you replace the old one and see what changed?
After the import
The useful part is what you do with it. Look for the ability to monitor an imported SBOM for newly published advisories, so a component that was clean last month raises an alert when something new appears. Check that you can record a supplier's statement that a vulnerability does not affect them, and that the statement is kept with its date and source.
Also confirm export in the other direction. If a customer asks you for an SBOM, can you produce one in their preferred format with the fields they ask for?
Try it yourself
Open the demo to see how a dependency inventory presents component, version and relationships. Compare it with what you get from your imported files.
Click through it at your own pace, or open it full screen.
Where Safeguard fits: Safeguard offers SBOM and dependency scanning, and you can try the free scan at gold.safeguard.sh/scan on your own repository.
Quick check
Which SBOM format should I ask suppliers for?
Accept both common formats if you can, and ask that identifiers and versions be present. Missing identifiers matter more than the format.
Last reviewed: 19 October 2026.
