An SPDX checksum is one line: an algorithm name such as SHA1, a colon, and lowercase hexadecimal. A CycloneDX hash is an object with an alg value such as SHA-1 and a content hex string. The names differ slightly, so converting between formats needs a mapping and a length check.
Side by side
In SPDX 2.3.1, the package checksum field is optional and can appear many times. It has three parts: an algorithm identifier, a colon separator, and a bit value as lowercase hexadecimal. The algorithms listed include SHA1, SHA224, SHA256, SHA384, SHA512, SHA3-256, SHA3-384, SHA3-512, BLAKE2b-256, BLAKE2b-384, BLAKE2b-512, BLAKE3, MD2, MD4, MD5, MD6 and ADLER32.
In CycloneDX 1.6 JSON, a hashes array holds objects with a required alg and a required content. The alg values are MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, BLAKE2b-256, BLAKE2b-384, BLAKE2b-512 and BLAKE3. The content is a hex string of 32, 40, 64, 96 or 128 characters.
PackageChecksum: SHA256: 11b6d3ee554eedf79299905a98f9b9a04e498210b59f15094c916c91d150efcd
{ "alg": "SHA-256", "content": "11b6d3ee554eedf79299905a98f9b9a04e498210b59f15094c916c91d150efcd" }
Mapping table
| SPDX | CycloneDX | Hex length |
|---|---|---|
| SHA1 | SHA-1 | 40 |
| SHA256 | SHA-256 | 64 |
| SHA384 | SHA-384 | 96 |
| SHA512 | SHA-512 | 128 |
| MD5 | MD5 | 32 |
The CycloneDX length list reflects the 32, 40, 64, 96 and 128 values above, which is why a 56 character SHA224 value cannot appear there even though SPDX allows SHA224. Converters need to drop or warn on algorithms one side does not support.
What the hash is a hash of
A hash only helps if the reader knows what was hashed. SPDX describes the package checksum as a way to verify, from the binary blob, which version or modification of a package the document references, and notes it shows that bits changed without saying which. It also says that if the SPDX document is included in the package, the package verification code field should be used instead, since a file cannot contain its own hash.
NTIA's 2021 report lists the hash of the component as a recommended field and notes it is hard when a tool did not have access to the underlying component, such as a binary analysis tool. In that case a hash may not be possible.
Validation checks worth automating
- Length matches the algorithm. A SHA-256 value must be 64 hex characters.
- Hex only. Reject spaces, prefixes like 0x, and uppercase if your policy requires lowercase, as SPDX does.
- Prefer a strong algorithm. MD5 and SHA-1 are in the lists, but a SHA-256 value is a better choice when you can provide one.
- Provide the hash of the same artifact the version refers to, such as the downloaded archive, not a file you rebuilt.
When the hashes disagree
Two SBOMs listing the same version with different hashes mean different bits. Treat it as a question to answer before the next release, not a formatting quirk.
Safeguard can generate SBOMs and run dependency scanning across your repositories, so the fields discussed here are checked on real projects instead of by hand. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Can I include several hashes for one component?
Yes. Both formats allow more than one, for example SHA-256 and SHA-512 for the same artifact.
Why does SPDX allow algorithms CycloneDX does not?
The two specs maintain separate lists. SPDX includes older and rarer algorithms such as SHA224 and ADLER32 that the CycloneDX 1.6 JSON enum does not.
Sources
- SPDX 2.3.1, Clause 7: Package information
- CycloneDX 1.6 JSON reference
- NTIA, The Minimum Elements for a Software Bill of Materials (2021)
Last reviewed: 19 October 2026.
