When a component keeps its version number but its hash changes between SBOMs, the bytes you received are different. Causes range from a different registry mirror or build flags to a republished package, and in the worst case tampering. Verify against the registry before you ship.
Why hashes matter in an SBOM
A version number is a label. A hash is a fingerprint of the exact content. If two builds record the same version with two fingerprints, they did not fetch the same file. A diff that compares only names and versions will not show this at all, so it needs a check on hashes.
Likely explanations
| Cause | How common | How to tell |
|---|---|---|
| Different hash algorithm or field recorded | Common | Compare the algorithm names, not just values |
| Hash taken from a different artifact type, such as sdist versus wheel | Common | Check the file name or qualifiers |
| Platform specific build, different operating system or architecture | Common | Look at package URL qualifiers |
| Package republished by its maintainer under the same version | Uncommon | Check registry history and release notes |
| Mirror or proxy serving altered or stale content | Uncommon | Fetch directly from the origin and compare |
| Malicious replacement | Rare, high impact | Treat as an incident until ruled out |
Do not assume the dramatic cause, and do not dismiss it either. Work down the table.
Steps
- Confirm both hashes use the same algorithm and the same artifact.
- Compare the package URL qualifiers, such as architecture, for both entries.
- Download the package from the official registry and compute the hash yourself.
- Compare against both recorded values. One should match, or neither.
- If neither matches, or the registry shows a republish, escalate to your security team and hold the release.
A related idea: reproducible builds
The reproducible builds project defines a build as reproducible when any party can recreate bit by bit identical copies of the artifacts from the same source, environment and instructions, and verification is done by comparing cryptographic hashes. If your own artifact hashes differ between two builds from the same commit, your build is not reproducible, and an SBOM diff will keep reporting differences you cannot explain.
Make it detectable
Record hashes in the SBOM where your generator supports it. Keep a lockfile with integrity values so the package manager itself rejects changed content. Prefer pulling through a controlled proxy, and log what it serves. Without those, the question "did the bytes change" is hard to answer later.
Hash checks do not prove a package is safe. They show that it is the same as before, or that it is not.
Safeguard scans dependencies and SBOMs and applies policies to component changes. Run a project through the free scan to see what is recorded for each component.
Quick check
Is a changed hash always an attack?
No. Different platforms, artifact types or recorded algorithms explain most cases. Rule those out first.
Does a matching hash mean the package is safe?
No. It means the content is the same as the one recorded, not that the content is free of flaws.
Sources
Last reviewed: 19 October 2026.
