A hash in an SBOM is a fingerprint of a software file, a short string made by running the file through a math formula. If even one byte of the file changes, the fingerprint changes. You can recompute the hash on a file you downloaded and compare it with the SBOM to see whether it is the same file.
TL;DR
- A hash is a fixed length fingerprint of a file. Same file, same hash. Different file, different hash.
- CISA's 2026 SBOM guidance adds Component Hash Value and Component Hash Algorithm as minimum elements.
- A match shows the file is the one the SBOM describes. It does not show the file is safe.
- A hash is only trustworthy if you trust where the SBOM came from, which is why signing matters.
Definition. A cryptographic hash is, in the 2026 guidance's words, the output of "applying a cryptographic hash algorithm" to a file. The result is written as a string of hexadecimal characters, which are the digits 0 to 9 and the letters a to f.
What is a hash, in plain words?
Imagine putting a book through a machine that prints a short code for it. Give the machine the same book tomorrow and it prints the same code. Change a single comma in the book and the code is completely different. You cannot rebuild the book from the code. You can only use the code to check a book.
That is a hash. Here is a real example you can try on your own computer. The word hello gives this SHA-256 hash:
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
Change one letter, to hellp, and you get this:
fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7
The two outputs share almost nothing, even though the inputs differ by one letter. That sensitivity is what makes hashes useful for catching tampering or corruption.
The name SHA-256 is the algorithm, the specific formula. There are several. That is why an SBOM needs to record the algorithm as well as the hash value. Without it, you would not know which formula to use to check.
What does CISA say about hashes in an SBOM?
The 2026 minimum elements for a software bill of materials, published by CISA with partner agencies from many countries, lists two new elements.
- Component Hash Value: "the output generated from applying a cryptographic hash algorithm to an executable component artifact." It should be an ASCII, hexadecimal encoded value. If the author does not have access to the executable component artifact, "the SBOM author should indicate the value is unknown."
- Component Hash Algorithm: the algorithm used to produce the value, so the integrity of the component can be validated. The author should name it using the Internet Assigned Numbers Authority (IANA) hash function textual names, and the algorithm should be approved by a relevant authority, such as NIST.
Both are marked as new compared with the 2021 version of the minimum elements.
You may also have seen hashes elsewhere. The npm documentation says each entry in a package lockfile can carry an integrity field: "A sha512 or sha1 Standard Subresource Integrity string for the artifact that was unpacked in this location." The idea is the same.
What does a hash prove, and what does it not prove?
It helps to be clear here, because hashes are easy to oversell.
| A matching hash shows | A matching hash does not show |
|---|---|
| The file is identical to the one the SBOM describes | The file is free of vulnerabilities |
| The file was not corrupted in transit | The file is free of malware |
| The file was not changed after the hash was recorded | The SBOM itself is honest |
| The same file is in two places | The component is a good choice |
The last point in the middle column is the important one. If someone replaces both the file and the SBOM, the new hash will match the new file. A hash checks consistency, not trust.
This is where signing comes in. The 2026 guidance adds an SBOM Author Signature element. Its definition: "A digital signature attributable to the SBOM author." The guidance says it "provides assurance that the claimed signatory signed the information and that the information was not modified after signature generation." So the signature protects the SBOM, and the hash in the SBOM protects the file. Together they form a chain.
How do I verify a file against an SBOM hash, step by step?
- Find the component in the SBOM. Locate its entry and read the hash value and the algorithm name.
- Get the file. This is the actual package or program you downloaded or received, not a copy of its description.
- Compute the hash with the same algorithm. On macOS or Linux, for SHA-256, run:
shasum -a 256 your-file.tgz
On Windows PowerShell, run:
Get-FileHash your-file.tgz -Algorithm SHA256
- Compare the two strings. They must match exactly, every character. Tools can compare for you, but a careful eye works for one file.
- If they match, note the result and move on.
- If they do not match, stop. Do not install the file. Re-download it from the original source and try again. If it still fails, ask the supplier.
- Check the SBOM's signature if there is one. A matching hash against an unsigned, unverified SBOM gives less assurance.
Be careful about one thing. Use the exact algorithm named in the SBOM. A SHA-256 value will never match a SHA-512 calculation of the same file, and that is not a sign of tampering.
Worked example: a supplier update
The details below are invented.
A company receives an update package from a supplier, along with an SBOM that lists the package's hash as a SHA-256 value. A staff member runs the check and gets a different result.
The investigation goes like this:
| Step | What the team finds |
|---|---|
| Compare strings | The values differ in the first few characters |
| Re-download | Same wrong result, so it is not a one time glitch |
| Check the algorithm | The SBOM says SHA-256, and the team used SHA-256 |
| Ask the supplier | The supplier confirms they rebuilt the package after generating the SBOM, and forgot to regenerate the SBOM |
| Fix | The supplier issues a corrected SBOM |
This is the benign ending. The mismatch was a process error, not an attack. But the team did exactly the right thing: it did not install until it understood the difference. The 2026 guidance supports the supplier's side too. It says authors should "correct errors promptly" and that an SBOM author who discovers an error "should issue a revised SBOM."
Where do hashes fit in a bigger routine?
A short checklist for the person who receives software:
- Ask for an SBOM that includes hashes and names the algorithm.
- Check at least your highest risk components against their hashes.
- Prefer a signed SBOM.
- Keep the SBOM and the hash check result with the release record.
- Treat unknown hash values as a gap to ask about, not as proof of a problem.
For related reading, see signed SBOMs and attestations and SBOM quality fields auditors check.
Try it yourself
In the demo below, open a package in the dependency inventory and look at what the tool records about it. Think about which of those details you would want to compare if a download arrived from someone else.
Click through it at your own pace, or open it full screen.
How can Safeguard help?
Safeguard's SBOM and dependency scanning builds an inventory of your dependencies and exports it in SPDX or CycloneDX, formats that can carry hashes. Its vulnerability management and reachability analysis address the question a hash cannot: whether a component has known flaws that your code can reach.
A free scan at gold.safeguard.sh/scan is an easy way to see an inventory for a real project. The Safeguard CLI and IDE extensions run the same scanning at the developer's desk, and the CLI can also write code for changes that a fix needs.
Quick check
If the hash matches, is the file safe?
No. A match shows the file is the one the SBOM describes. The file itself could still have flaws or be a poor choice. Pair hash checks with vulnerability scanning.
Why does the SBOM name the hash algorithm?
Different algorithms produce different values for the same file. You need to know which one to use to check.
What if the SBOM says the hash is unknown?
Current guidance says authors should mark a value as unknown if they cannot get the file. Treat it as a gap, and ask the supplier if the component matters to you.
Sources
- CISA and partners, 2026 Minimum Elements for a Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- npm Docs, package-lock.json: https://docs.npmjs.com/cli/v10/configuring-npm/package-lock-json
Last reviewed: 19 October 2026.
