A platform should import at least the two formats the NTIA guidance names as common, SPDX and CycloneDX, in the versions your suppliers actually send, and it should handle bad or partial files without silently dropping data. The only reliable proof is a test set of your own files.
Why the claim "supports SPDX and CycloneDX" is not enough
Each format has several spec versions, and each version can be written in more than one serialization, such as JSON or XML, and SPDX also has a tag value form. A product might parse one combination well and another poorly. The SPDX specification itself is organised into clauses for document creation information, package information, file information, relationships and annotations, so a lot of meaning lives in fields that a lazy importer could skip.
NTIA lists SPDX, CycloneDX and SWID tags as data formats used to generate and consume SBOMs, and says formats should support automation. Ask which of those a product reads, and which it only stores as an attachment.
Build a test set
Collect ten to fifteen files before the trial.
- One clean file per format and version you expect to receive.
- One file in each serialization you expect.
- A large file from a real product with thousands of components.
- A file with no relationships, only a flat list.
- A file with missing versions and unknown suppliers.
- A file with a deliberately broken field, such as a malformed identifier.
- A file with extensions or custom properties.
- A file from a supplier tool you do not control.
What to look for in the result
| Check | Pass looks like |
|---|---|
| Component count | Matches the source file |
| Relationships | Parent child links preserved |
| Identifiers | Package URLs or other IDs kept verbatim |
| Licenses | Expressions preserved, not flattened |
| Broken file | Clear error or warning, not a silent partial load |
| Unknown fields | Kept or reported, not discarded without notice |
| Large file | Loads in reasonable time without timing out |
Count components before and after, then spot check twenty at random. A mismatch in count is the most common and most useful signal.
Ask about the failure path
How does the platform report a file it cannot parse? A message that names the line and field is helpful. A green tick with half the data is dangerous. The article on what to do when an SBOM file fails to parse covers diagnosis, and validating before you accept one covers the front door.
Ask about normalisation
When the same component arrives from two formats with slightly different names, does the platform recognise them as one? Canonical identifiers help here. See how to deduplicate components across many SBOMs.
Where Safeguard fits
Safeguard scans repositories and images to produce SBOM and dependency inventories, and it can be tried first on your own code with the free scan at gold.safeguard.sh/scan. Confirm any import behaviour against your own test files, as described above.
Quick check
Do I need to test every supplier file?
Test one file per supplier tool, not one per supplier. Different suppliers using the same generator tend to produce similar output.
Is a platform that stores an SBOM as an attachment good enough?
Only if you never need to search, match or diff it. Attachment storage gives you a file cabinet, not management.
Sources
Last reviewed: 19 October 2026.
