The same service ends up on different versions because deployments are triggered separately, some pipelines fail quietly, and some accounts are updated on slower schedules. The result is version drift. Detect it by recording the deployed version and image digest per environment and comparing them to the latest release.
What drift looks like
You fix a vulnerable dependency, release version 2.4.1, and close the ticket. Production in one account moved. A second account still runs 2.3.9 because its pipeline paused during a freeze. An on premises site was never connected to the new pipeline. The advisory is now fixed in one place and open in two, and the ticket says done.
Why it happens
- Freezes and change windows that differ by site.
- Manual deployments that skip the pipeline.
- Failed rollouts that revert silently.
- Pinned image tags that never move, since a tag can be reused or changed while a digest cannot.
- Accounts owned by different teams with different habits.
Record the right fields
Kubernetes documents recommended labels including app.kubernetes.io/name and app.kubernetes.io/version. Equivalent fields in other platforms work too. What matters is that you can query three things for every deployment.
| Field | Why |
|---|---|
| Service name | Groups deployments |
| Deployed version | Human readable release |
| Artifact digest | Proves exactly what runs |
Version labels can be wrong, since someone can set them by hand, so the digest is your evidence.
A weekly drift check
- Pull deployed versions and digests for every service from each environment.
- Compare each to the latest released digest.
- List deployments more than one release behind, or behind a release that fixed a security finding.
- Send the list to owners with the fix target.
- Track how long each deployment has lagged.
Pay special attention to deployments behind a security fix, because they are the ones where a closed ticket is misleading.
Fix the causes
If one environment lags often, ask why. If the cause is a freeze policy, build an emergency path for security fixes. If it is a missing pipeline, connect it. If it is a manual process, replace it, or at least record it.
Close tickets on deployment evidence
Do not close a vulnerability ticket when the pull request merges. Close it when each listed deployment shows the fixed digest.
Try it yourself
Open the continuous monitoring demo and watch how a changed state is picked up over time. Think of drift as a change you want to notice the same way.
Click through it at your own pace, or open it full screen.
An example of a drift report
For service orders-api: latest release 3.1.0, which fixed a security finding. Account A runs 3.1.0. Account B runs 3.0.4 and has done so for five weeks because of a freeze. The data centre site runs 2.9.8 and was never connected to the pipeline. The report sends account B and the data centre owners a short list with the fix target, and the weekly review checks both items next time.
Quick check
Is some drift acceptable?
Yes, for ordinary releases. Drift behind a security fix is the kind to limit, with a deadline.
Is the version label enough evidence?
No. Use the digest, since labels can be edited by hand.
Safeguard's continuous monitoring and asset discovery help keep deployed state visible. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
