A clean build SBOM does not prove production is clean. Before declaring a product not affected, confirm that the artifact running in production is the one the SBOM describes, by comparing image digests, checking base layers and looking for anything installed after the build. If you cannot confirm, say it is under investigation.
Why they diverge
An SBOM describes what was true when it was generated. Production can differ in several ways:
- The deployed image is an older or newer build than the one that was scanned.
- The base image was rebuilt with newer packages after the SBOM was created.
- A startup script or init step installs packages at runtime.
- A hotfix was applied directly to a running system.
- The SBOM came from source and lockfiles, while the artifact includes extra files.
The related post on six SBOM types explains why source, build, analyzed, deployed and runtime views can disagree.
Checks in order
- Get the digest or hash of what is actually running, not the tag. Tags can move.
- Compare it with the digest recorded alongside the SBOM. If they differ, the SBOM does not describe production.
- Inspect base image layers. If the SBOM was produced from source only, OS packages may be missing from it.
- Search the running artifact for the component directly, using a scan of the image rather than the earlier SBOM.
- Look for runtime package installs in entrypoint scripts and orchestration config.
- Check whether the product loads plugins or extensions that bring their own dependencies.
Decision table
| Finding | Meaning | Verdict |
|---|---|---|
| Digest matches, SBOM is full depth | SBOM describes production | Use the SBOM result |
| Digest matches, SBOM is shallow | Components may be missing | Rescan the artifact |
| Digest differs | SBOM is for another build | Generate a new SBOM for the deployed artifact |
| Runtime installs found | Build SBOM is incomplete | Treat as unknown until scanned at runtime |
| Cannot identify the running artifact | No basis for a claim | Under investigation |
Record what you did
Write the verdict with its evidence: the digest checked, the tool that scanned it and the time. If you later publish a VEX statement, that evidence is what a not affected justification should rest on.
Preventing the gap
Store the SBOM with the image digest, regenerate it when the base image changes, and avoid installing packages at container start. Attaching SBOMs to images makes the link harder to lose; see attaching an SBOM to a container image.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how base layer packages appear separately from application dependencies.
Quick check
Is an image tag enough to identify what runs?
No. Tags can be moved to a different build. Use the digest.
Do we rescan or trust the stored SBOM?
Trust it only when the digest matches and its depth is sufficient. Otherwise rescan the deployed artifact.
Safeguard's container image scanning and continuous monitoring can scan what is deployed, not just what was built.
Last reviewed: 19 October 2026.
