Check build to production drift by recording an SBOM for every deployed version, then regularly comparing it with an inventory taken from the running system. Components present in production but not in the build record point to manual changes, hotfixes outside the pipeline, or an untracked deployment.
What drift means here
Build time SBOM drift is about releases changing. Runtime drift is about reality departing from the record. A container started from image A, then patched by hand, then restarted from image B can make your records wrong without any release happening. The SBOM you filed no longer describes the system.
Steps
- At deploy, store the SBOM with the exact image digest or build identifier that was deployed.
- Keep a map from each environment and service to the version that should be running.
- On a schedule, generate an inventory from the running workload, for example by scanning the live image or host.
- Diff the runtime inventory against the stored SBOM for that version.
- Route any difference to the service owner with the component list.
Classifying what you find
| Difference | Typical cause | Response |
|---|---|---|
| Whole version mismatch | Rollback, failed deploy, forgotten instance | Redeploy or update the record |
| Extra packages in production | Manual install during an incident | Remove, or fold into the next build |
| Missing components | Different scan scope or a stripped image | Fix scope, then re-diff |
| Extra running service | Untracked or shadow deployment | Find the owner, register it |
| Same version, different content | Mutable tag, republish | Pin by digest, investigate |
Why a mutable tag causes drift
A tag such as latest can point to new content later. Two nodes started on different days can run different software under the same label. Deploy by digest, and record the digest. Then "what should be running" has a single answer.
Limits to keep in mind
A runtime inventory only sees what your scanner can reach. Statically linked binaries, vendored code and anything loaded from outside the image may not appear. Treat a clean comparison as evidence that no known drift exists, not as proof that none exists.
Document the scope of every comparison: what was scanned, how, and when. A reviewer reading a result without its scope will assume it covered more than it did.
Who owns the follow up
Drift findings need an owner, not just a report. Assign by service, and set an expectation, for example that unexplained differences are resolved or recorded within an agreed period. Without that, the reports pile up.
Safeguard includes asset discovery and continuous monitoring alongside SBOM and dependency scanning, which supports keeping the record and the running inventory side by side. See the free scan for a quick look at a project.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a change after deployment is surfaced and attributed.
Quick check
How often should I compare runtime with the stored SBOM?
Pick a schedule you can act on, such as daily for critical services. Findings nobody reads add nothing.
What is the simplest way to reduce drift?
Deploy images by digest and rebuild instead of patching running systems by hand.
Last reviewed: 19 October 2026.
