In SPDX, a package checksum is a reproducible hash that identifies a specific package as shipped, such as a tarball. A package verification code is a reproducible hash derived from the contents of the files, which lets you check which files changed. Firmware teams often need both.
The definitions
SPDX 2.3.1 package information describes the fields this way.
- Package checksum. A reproducible mechanism that permits unique identification of a specific package, using algorithms such as SHA1 or MD5 in the specification text. It identifies the artifact you downloaded.
- Package verification code. An independently reproducible mechanism that permits unique identification of the contents of the files. It is used to check which files changed.
- Package download location. The URL, or a specific location within a version control system, where the package can be obtained.
- Files analyzed. A true or false flag for whether the package's file contents were available for or subjected to analysis. The default is true.
The specification also provides an external reference field with categories including SECURITY, PACKAGE-MANAGER, PERSISTENT-ID and OTHER.
Why firmware teams care
Firmware libraries are often vendored. You copy a tarball into the tree, apply two patches and rebuild. Now the question is: is this still the upstream package?
| Question | Field to use |
|---|---|
| Is this the exact archive I downloaded? | Package checksum |
| Do the files in my tree still match what I recorded? | Package verification code |
| Where did it come from? | Download location |
| Did anyone actually look inside? | Files analyzed |
A checksum of the upstream archive tells you what you started with. After you patch, the archive hash no longer describes your tree, but a verification code computed over the files can be recomputed later to see whether anything drifted.
A practical routine
- Record the upstream version, download location and archive checksum at import time.
- Record patches separately, with a description and the reason.
- Compute the verification code over the files you actually build.
- Recompute it in CI. A change means someone edited vendored code outside the process.
Limits
These fields describe identity, not safety. They do not say whether the component has vulnerabilities, and they do not replace a version that a scanner can match to an advisory. Use them to support the version, not to stand in for it.
Where Safeguard fits
If you want an inventory your reviewers can query, Safeguard offers SBOM and dependency scanning with policies and gates on pull requests. It works from the source and manifests it supports. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Open a component and look at what identifies it. Ask whether you could prove the files in your tree match it.
Click through it at your own pace, or open it full screen.
Quick check
Which algorithm should I use for checksums?
The specification text mentions SHA1 and MD5 as examples. Prefer a stronger algorithm such as SHA256 where your tooling allows it.
Do I need a verification code for every package?
It is most useful for vendored or patched code, where you want to detect later edits.
Sources
Last reviewed: 19 October 2026.
