Often yes for the core fields, not always for everything. Names, versions, identifiers and relationships usually map. Format-specific extras may not. Convert only to feed your tools, keep the original file untouched, and compare the component count and a sample of fields before and after you use the result.
What the standards say
The NTIA minimum elements report names SPDX, CycloneDX and SWID tags as formats used to generate and consume SBOMs. It also records the view of SBOM community members that computers are good at format conversions, and that interoperability and automated translation tools matter more than picking a single format. In other words, conversion was expected from the start.
The same report requires the seven data fields to be present in whichever format is used. If those seven survive conversion, the file still meets the data field list, though it may lose other information.
When you need to convert
- Your tool reads only one format.
- You are merging SBOMs from suppliers that use different formats.
- A supplier cannot produce the format you prefer.
If a supplier can produce the format you want at no cost to them, ask first. A native export beats a converted one.
Step by step
- Keep the original. Store the supplier file untouched. It is your evidence of what you received.
- Convert with a maintained tool. Use a well-known open source converter or your platform's import. Note its name and version.
- Count components before and after. A mismatch means something was dropped or split.
- Spot check ten components. Compare name, version, supplier and identifier.
- Check relationships. Open both files and see whether the dependency links survive.
- Record the conversion. Tool, version, date, who ran it. The NTIA report distinguishes the author of SBOM data from the supplier, and the converter is now part of that history.
What commonly needs a closer look
| Area | Why it may differ |
|---|---|
| Dependency relationships | The two formats express them differently |
| License fields | Expression syntax and concluded versus declared values can vary |
| Hashes | Algorithm names and placement differ |
| Custom properties | Format-specific, often dropped |
| Document metadata | Author and timestamp fields may map imperfectly |
Do not assume a clean run means a clean result. Converters rarely complain about data they silently omit.
Handling VEX alongside
VEX information has its own formats. CycloneDX supports VEX, and the OpenVEX specification is a separate format. Do not convert an SBOM and assume the exploitability statements came with it. Check separately.
Decision guide
If it is a one-off review, convert and move on. If the supplier will send files for years, ask for the format you prefer, in writing, as part of delivery. If the converted file feeds a compliance record, keep both and note the conversion.
Safeguard's SBOM and dependency scanning can read your component lists, and the free scan at gold.safeguard.sh/scan accepts CycloneDX and SPDX.
Quick check
Is a converted SBOM still the supplier's SBOM?
The data comes from them, but you authored the conversion. Keep the original and record who converted it.
How do we know nothing was dropped?
Compare component counts and spot check fields. If counts differ, investigate before using the converted file.
Sources
- The Minimum Elements For a Software Bill of Materials (SBOM), NTIA
- Vulnerability Exploitability eXchange (VEX), CycloneDX
- OpenVEX specification
Last reviewed: 19 October 2026.
