A supplier SBOM usually fails to parse for one of seven reasons: wrong file type or encoding, truncated content, a version your parser does not support, a schema violation, duplicate reference IDs, malformed identifiers, or an invalid timestamp. Work through the checks in order, then send the supplier the exact error.
Start with the file, not the format
Before blaming the SBOM standard, confirm the file itself is sound. Many failures are mundane.
Checklist
- File type and extension. Is it JSON, XML or another encoding? A renamed file confuses detection. Check the first bytes, not the name.
- Encoding. A byte order mark or an unexpected character set can break strict parsers.
- Truncation. Compare size with what the supplier sent. A cut off download ends mid-object. Verify the hash if one was provided.
- Spec version. Check the declared version and whether your parser supports it. Newer versions add fields that older parsers reject.
- Schema validity. Validate against the published schema for that version. Missing required fields and wrong types show up here.
- Duplicate reference IDs. CycloneDX requires each reference identifier to be unique within the BOM. Duplicates often come from merged documents.
- Serial number format. CycloneDX defines the serial number as a URN with a lowercase UUID. Uppercase or missing prefix fails strict checks.
- Identifier validity. A purl that is present must be valid under the purl specification.
- Timestamp format. SPDX requires the created field in UTC in a fixed pattern ending with Z. A local time zone offset fails.
- Namespace and references. SPDX document namespace must be an absolute URI without a fragment character.
Read the error like a map
| Symptom | Likely cause |
|---|---|
| Fails at line one | Encoding or wrong type |
| Fails near the end | Truncation |
| Fails on unknown field | Newer spec version than the parser |
| Fails on duplicate | Merged or hand edited file |
| Parses but empty | Generator saw no dependencies |
Report back usefully
Send the supplier a short note: file name, hash, your parser and version, the exact error message, and the suggested fix. Offer to accept an alternate format. Keep a log, so patterns, such as one generator that always emits uppercase UUIDs, can be fixed at the source.
Do not hand edit supplier files
It is tempting to patch a file so it loads. Resist. Edits break the chain of evidence. If you must fix something to proceed, keep the original and record what you changed and why.
Try it yourself
Click through it at your own pace, or open it full screen.
See what a healthy inventory looks like, as a contrast to the files that fail the checks above.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning that you can try with the free scan, a quick way to test whether a file loads and what it contains.
Quick check
Should I fix a malformed SBOM myself?
Keep the original untouched. Return the error to the supplier, and record any change you make to proceed.
A file parses but shows no components. Is that a parse error?
Not strictly. It is a quality problem, so quarantine it and ask the supplier.
Sources
- CycloneDX 1.6 JSON reference: serial number format, reference uniqueness, purl validity.
- SPDX 2.3.1, document creation information: created format, namespace rules.
Last reviewed: 19 October 2026.
