To compare a hash from a write-up, compute the same kind of hash, usually SHA256, of the exact file you installed or built, then compare it character by character with the published value. A match means the files are identical. A mismatch means they differ. Neither result alone says whether a file is safe.
Why write-ups list hashes
An incident write-up that names a bad file often adds a hash. A hash is a short fingerprint of a file's contents. If two files have the same SHA256, they are, for practical purposes, the same file. That lets you check without sharing the file or describing its contents.
For you, a hash from a report is a precise way to ask: do we have this exact file anywhere? It is much sharper than a version number, because a version number is a label and a hash is the content.
What a match and a mismatch mean
| Result | What it tells you | What it does not tell you |
|---|---|---|
| Match with a hash the write-up calls bad | You have the exact file described as bad | Whether it ran, or what it reached |
| Match with a hash the registry published for your version | Your copy equals the published file | Whether the published file is harmless |
| Mismatch with the bad hash | Your file is not that exact file | That it is safe, since an attacker can change files |
| Mismatch with the published hash | Your copy differs from what the index published | Why, which could be a mirror, a rebuild or tampering |
Treat the result as one piece of evidence. A match on a bad hash is strong. A mismatch on a bad hash is weaker, because malware authors can alter a file slightly and change its hash.
Step 1: identify which file you are checking
Hashes apply to files, not to package names. Decide which file the write-up means.
- For a Python package, it is usually the wheel or source archive for a release.
- For an npm package, it is usually the tarball for a version.
- For a container image, it may be an image digest or a file inside a layer.
- For a downloaded installer, it is the installer file.
The PyPI JSON API documentation says release entries include hash digests, MD5, SHA256 and BLAKE2b-256, keyed by release version. That is a good source for the published digest of a Python file.
Step 2: get the file you actually have
Use the copy from your own system, not a fresh download. A fresh download tells you what the registry serves today. Your question is about what you installed then.
- Look in your package manager cache, your build artifacts or your container layers.
- For npm, you can fetch the tarball for a version with
npm pack some-package@1.2.3, which the npm documentation describes as copying the tarball into the current directory. Remember that this fetches what the registry serves now. - If you keep hash pinned requirements or lockfile integrity values, those record what you asked for at install time.
Step 3: compute the hash
On macOS:
shasum -a 256 some-file.tgz
On Linux:
sha256sum some-file.tgz
On Windows PowerShell:
Get-FileHash some-file.tgz -Algorithm SHA256
Make sure the algorithm matches the one in the write-up. A SHA256 value will not match an MD5 value of the same file, and a mismatch there means nothing.
Step 4: compare carefully
Compare the full string, not the first few characters. Paste both into a text file and let a tool compare them, or use a command:
echo "PUBLISHED_HASH some-file.tgz" | shasum -a 256 -c
Eyeballing long strings invites mistakes. Also check for case and stray spaces, which can make equal values look different.
A worked example
A write-up says the malicious file for version 1.9.0 of a library has a particular SHA256, and the clean 1.8.9 has another. You run the library in two builds.
You find the cached tarballs for both builds in your build artifacts. Build A has a tarball whose hash matches the clean 1.8.9 value. Build B has a tarball whose hash matches the bad 1.9.0 value.
Your conclusion for Build A is that it used the clean release, with the hash as evidence. For Build B, it contained the file the write-up calls bad, so you treat the build as exposed, check whether it ran, and rotate the secrets its environment could read.
Neither conclusion relied on a version number or a package page. Both rest on file contents.
What to write down
Record the file name, where you found it, the algorithm, the computed hash, the published hash, the time and who did it. Keep the output of the command. If the write-up changes its hash later, you can show what you compared against.
Try it yourself
Click through it at your own pace, or open it full screen. Use it to think about where files live inside an image, which is where you would look for a file whose hash a write-up names.
Safeguard's SBOM and dependency scanning records the components and versions inside what you build, which helps you find where a named file might sit before you hash it.
Quick check
Does a matching hash prove a file is safe?
No. It proves two files are identical. If the published file is malicious, a match means your copy is malicious too.
Should I hash a fresh download or the file I installed?
The file you installed. A fresh download shows what the registry serves now, which may differ from what you fetched earlier.
Does it matter which hash algorithm I use?
Yes. Use the same algorithm the write-up or registry used. Hashes from different algorithms of the same file will never match each other.
Sources
Last reviewed: 19 October 2026.
