Yes, you can test it: import an SBOM, export it in the same format, and compare the two files field by field. If components, identifiers, relationships and licenses match, the platform keeps your data intact. If not, you have found a risk before it became a contract.
Why this matters
Export is half of the NTIA idea of sharing. The guidance describes distribution and delivery as an operational practice, and your customers, regulators and auditors will ask for SBOMs in a standard format. If a platform stores a lossy copy, every export carries the loss. You will not notice until a customer's tool rejects the file or reports fewer components than yours.
Export is also your exit route. Data you cannot get out in a usable form is not really yours.
The test, step by step
- Pick three source files. One small and clean, one large and real, one messy with gaps.
- Record a baseline. Count components, relationships and distinct licenses in each source file with a small script or a standard validator.
- Import each file. Note any warnings the platform shows.
- Export in the same format and version. Then, if offered, export in the other main format.
- Compare. Run the same counts on the exported files and diff the identifiers.
- Validate the export. Check it against the format's schema with a command line validator. See validate SBOM files from the command line.
- Feed it back in. Import the export into the platform again. The result should equal the first import.
What a good result looks like
| Item | Expected |
|---|---|
| Component count | Identical |
| Package URLs and other identifiers | Identical strings |
| Dependency relationships | Same parent child pairs |
| License expressions | Same text, not simplified |
| Supplier and author | Preserved |
| Timestamp | Original creation time kept, or a clear new export time labelled as such |
| Custom properties | Kept, or listed as dropped |
Some differences are acceptable and even correct. An exporter may add its own tool name to the metadata. A platform may add enrichment such as vulnerability data if you ask for it. What you want is that nothing from the source disappears without a note.
Watch the timestamp and author
A subtle trap: the export may overwrite the author and timestamp with the platform's own, which makes an old SBOM look freshly generated. NTIA lists both as baseline fields, and a reader will use the timestamp to judge freshness. Make sure the original creation data survives, or that a separate export time is recorded. The same applies when you version and timestamp an SBOM document.
Cross format export
If the platform converts between formats, test that too, but expect some loss, because the two formats model things differently. Ask for a list of fields that do not map. A written list is a good sign. A vague answer is not.
Keep the results
Save the comparison as an evidence file. It supports the evaluation record and answers a later question about why you chose a tool.
Where Safeguard fits
Safeguard produces SBOM and dependency inventories from scans. You can run the free scan at gold.safeguard.sh/scan and use the result as one of your test files for any tool you assess.
Quick check
Should the exported file be byte identical to the imported one?
Not necessarily. Ordering and metadata can differ. The content that matters, components, identifiers, relationships and licenses, should match.
How long does a round trip test take?
For three files and a command line validator, under an hour once the files are ready.
Sources
Last reviewed: 19 October 2026.
