Confirm the rollout finished, confirm the running pods use the image you intended, read policy and audit events for surprises, check that exposure and access did not change, and watch error signals. Decide in advance what result means roll back. Most of this can be a script that runs after every release.
Why the first hour matters
A security deploy is a change under time pressure, which is when mistakes happen. The release can succeed on paper while the old vulnerable pods still run, or a new policy can quietly block part of the fleet. A short, repeatable check finds both.
The checklist
- Rollout finished. Run kubectl rollout status. The Deployment documentation says it returns a zero exit code on success and a non-zero one when the progress deadline is exceeded.
- Right image running. List the images of running pods and compare digests to the release record. A tag that was reused could hide an old image.
- No old versions left. Look for pods still on the previous ReplicaSet, and for other workloads using the same vulnerable component.
- Policy events. Read events and audit entries for admission denials or warnings tied to the release.
- Exposure unchanged. Confirm Services, Ingresses and network policies match what you intended.
- Access unchanged. Check service accounts and role bindings did not grow.
- Health signals. Compare error rate and latency to the hour before.
- Findings updated. Rescan or confirm monitoring now shows the finding closed.
Quick commands
kubectl rollout status deployment/web
kubectl get pods -l app=web -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.status.containerStatuses[*].imageID}{"\n"}{end}'
kubectl get events --sort-by=.lastTimestamp
Adjust labels and namespaces to your setup. The imageID field shows the resolved image, which is what you compare to your record.
Decide the rollback trigger in advance
Write it down before the deploy.
| Signal | Suggested action |
|---|---|
| Rollout stalls past the deadline | Investigate events, then decide rollback or fix forward |
| Error rate clearly above baseline for a set window | Roll back, if the older version is acceptable |
| Policy denial blocks part of the fleet | Fix the manifest or apply a narrow, logged exception |
| Fix is incomplete, vulnerable pods remain | Do not close the incident, continue rollout |
A rollback to an older revision restores only the pod template, so check whether the old image is itself vulnerable before choosing it.
Close the loop
When checks pass, record the result: release, digest, time, who checked, and the findings closed. That entry is your deployment evidence, and it helps the next release go faster. If the checklist found something, add a check for it, so the same miss is not repeated.
Where Safeguard fits
Safeguard's continuous monitoring keeps tracking findings after release, so you can see the finding close on the project, and its compliance and evidence automation helps keep the record of what was checked.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how status updates after a change lands.
Quick check
How do I know the new image is really running?
Compare the resolved image digests of running pods with your release record, not just the tag.
Should I always roll back on a failed check?
Not always. The older version may itself be vulnerable. Decide between rollback and fix forward using your pre-agreed triggers.
Sources
Last reviewed: 19 October 2026.
