SBOM component hashes: what to include and which algorithm

Include a cryptographic hash of each component's artifact and name the algorithm next to it. The 2026 CISA minimum elements add component hash value and hash algorithm as two fields. Pick a SHA-2 or SHA-3 family hash rather than MD5 or SHA-1 where you have the choice.

Why a hash helps

A name and version say what a component claims to be. A hash lets a reader check that the file in front of them is the one you described. It makes matching a component to a registry file more reliable than matching by name, and it helps spot a tampered or substituted package.

What to hash

Hash the thing you received or built: the package archive, the container layer, the library file. A hash of the manifest entry is not useful. Record the algorithm with the value, because a bare string of hex digits cannot be interpreted safely.

CycloneDX hashes

In the CycloneDX 1.7 JSON reference, a component's hashes are an array of objects, each with an alg and a content value. Allowed algorithms include MD5, SHA-1, the SHA-2 family (SHA-256, SHA-384, SHA-512), the SHA-3 family, BLAKE2b, BLAKE3 and Streebog. The content must be a hexadecimal string whose length matches the algorithm, which the schema lists as 32, 40, 64, 96 or 128 characters.

An example in a code block:

"hashes": [
  { "alg": "SHA-256", "content": "put-the-64-hex-characters-here" }
]

SPDX has two hash ideas

SPDX 2.3.1 distinguishes a package checksum from a package verification code.

• The package checksum is a hash of the whole package archive. Several checksums with different algorithms are allowed.
• The package verification code is computed from the files inside a package. You hash each file, skip excluded files such as the SPDX document, sort the hashes, join them, and hash the result with SHA1. It is optional and must be omitted when files analyzed is false.

The spec notes that if the SPDX document will be included inside the package, the verification code should be used instead of the checksum, since the document can be excluded from the calculation.

Practical advice

1. Take hashes from the package manager or registry metadata where available, and verify them against the file you hold.
2. Provide at least one strong algorithm. Add a second only if a consumer needs it.
3. If you cannot produce a hash for a component, mark it as missing in your cover note rather than inventing a value.
4. Re-hash on every build. A changed file with an old hash is worse than no hash.

Hashes tell a reader which file you meant. They do not tell anyone the file is safe.

Quick check

Sources

• FOSSA, CISA releases 2026 minimum SBOM elements
• CycloneDX 1.7 JSON reference
• SPDX 2.3.1 specification, package information

Last reviewed: 19 October 2026.