Record a cryptographic digest of the released image inside the SBOM, along with the version and build identifier, and store the two together. Then a unit in the field, or a file a customer holds, can be hashed and matched to the exact document that describes it.
The problem
Firmware versions get reused, rebuilt and patched. A version string like 2.4.1 may exist as a release candidate, a signed release and a hotfix build with the same label. If your SBOM refers only to the version, it may describe a different binary from the one on the device.
An SBOM that does not identify its subject is closer to a rumour than a record. The fix is cheap: bind it to a digest.
What to record
- The digest of the final image that you sign and ship, using a standard hash algorithm. Hash the file in its released form, including any packaging.
- The version string and, separately, a build number or commit identifier.
- The hardware targets that image supports.
- The time of the build, in a standard format.
Both common SBOM formats can hold hashes on the top level component. Put the digest there, not in a free text note.
Where the digest comes from
Compute it as the last step of the release pipeline, after any signing or packaging, because those steps change the bytes. If you hash before signing, the digest will not match the file you ship.
Be clear about which file the digest covers. A raw image, an update package and a compressed archive all have different digests. State which one the SBOM refers to.
Matching in the field
When a customer or support engineer asks which SBOM applies, the steps are:
- Get the image or read its digest from the update service.
- Search your SBOM store for that digest.
- If found, you have an exact match. If not, look up by version, and treat the match as unconfirmed.
Store them together
Keep image, signature, SBOM and build record in the same release folder or artifact entry. Use the same retention rule for all of them. If you keep images for the support life of the product, keep the SBOMs for that long as well.
Watching for new advisories
A bound SBOM can be re-checked against new advisories after release. Because it names an exact image, the answer to "is this release affected today" is clear. Without the binding, you would be guessing which units the new advisory touches.
Try it yourself
Open the continuous monitoring demo and see how a stored inventory is re-checked as new advisories appear. That only works when the stored record matches what shipped.
Click through it at your own pace, or open it full screen.
Safeguard generates SBOMs and supports continuous monitoring of the dependencies in them. Adding the final image digest is a release pipeline step on your side, so include it in your checklist. You can start with a free scan.
Quick check
Is the version number enough to identify an image?
No. Versions get reused. A digest identifies the exact bytes.
When do I compute the digest?
After signing and packaging, as the last pipeline step, on the exact file you distribute.
Last reviewed: 19 October 2026.
