Confirm by checking the running system, not the pipeline. Compare the deployed image digest or build ID with the release, read the version from the live service, check the SBOM of what is running, rescan the live artifact, and replay the exploit test against production.
Why a green pipeline is not proof
A release can be tagged and published while a stale replica, a cached image, a forgotten region or an old worker pool still runs the previous build. Rollouts can also stall without a loud failure. Treat "deployed" as a claim that needs evidence.
Five checks
| Check | What it proves | Typical source |
|---|---|---|
| Digest or build ID match | The runtime is the artifact you released | Orchestrator, registry, host agent |
| Version endpoint or banner | The service reports the new version | Health or about endpoint |
| SBOM of the running artifact | The fixed component version is inside | Build output or image scan |
| Rescan of the live artifact | The finding no longer appears | Scanner, run against the deployed image |
| Behavior test | The exploit or bad input is now rejected | Safe test request |
Steps
- Write down the expected digest or build ID before the rollout starts.
- After the rollout, list every running instance and its artifact ID. Count them. The number must equal what you expect, and all must match.
- Include the places people forget: batch jobs, scheduled tasks, staging mirrors that face the internet, disaster recovery regions and customer-hosted copies.
- Fetch the SBOM of the running artifact and confirm the component is at or above the fixed version.
- Run the same test that failed before the fix. A regression test in CI is good, but one request against production is better evidence.
- Record the result with a timestamp. That record is your proof if someone asks later.
# example: list unique image digests across running pods in one namespace
kubectl get pods -n prod -o jsonpath='{range .items[*]}{.status.containerStatuses[*].imageID}{"\n"}{end}' | sort | uniq -c
If that prints more than one digest, the rollout is not finished.
What to do when the numbers disagree
Do not declare done. Find out whether the extra digest is a stuck rollout, a separate service that shares the vulnerable component, or an environment you forgot. Fix, then repeat the count.
Hosted versus customer-run
For your own hosted service, you can do all five checks. For software customers run themselves, you cannot see what version they have. Publish the minimum safe version, make it easy to see in the product, and keep guidance current. Your released fix is only the start.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a component that was fixed stays watched, so a regression shows up again.
Safeguard continuously rescans what you run, which gives you an independent check that a fixed component is actually gone. A free scan is at gold.safeguard.sh/scan.
Quick check
Is the release tag enough to prove deployment?
No. The tag shows what was built. Only the running system shows what is live.
What if one instance still runs the old build?
Treat the fix as not deployed. Find out why it was missed, update it, and repeat the count.
Last reviewed: 19 October 2026.
