Rolling back restores a working state, but it can also reintroduce vulnerabilities that the newer release fixed. Treat a rollback as a release of its own: know the target's scan results in advance, time-limit the exposure, and plan to roll forward with a fix.
The hidden trade
Teams usually judge a rollback on one question: does it stop the outage? The security question is the second one: what did the newer version fix that we are now bringing back? If the release you are leaving contained a security patch, rolling back reopens that hole, sometimes while the flaw is already being exploited.
Prepare before you need it
- Keep the previous release's scan result and SBOM in the release evidence pack, so you can see its findings without scanning in a hurry.
- Mark which releases contain security fixes. A one line tag in the release record is enough.
- Pin artifacts by digest. Kubernetes documentation notes that tags can be moved to point to different images while digests are fixed, and that using the latest tag makes it harder to track which version runs and to roll back properly. Rolling back to a tag that has since moved is not a rollback.
- Define a maximum time on a vulnerable rollback target, such as a single business day, after which a decision is required.
A rollback decision table
| Rollback target has | Action |
|---|---|
| No known blocking findings | Roll back, then investigate |
| Findings that the failed release fixed, not exploited | Roll back with a time limit and a roll-forward plan |
| Known exploited findings reachable on exposed paths | Prefer a forward fix, or roll back behind a mitigation |
A mitigation can be as simple as disabling a feature flag, tightening a network rule or blocking an endpoint at the edge while the old version runs.
Record it
A rollback is a change. Record who decided, the reason, the findings that came back, the mitigation applied and the time limit. This is the sort of record a change management control expects, since NIST SP 800-53 CM-3 calls for documenting configuration change decisions and retaining records of them.
After the rollback
Fix the cause of the failed release, rebuild, run the full gate and roll forward. Then ask whether the rollback target should still be allowed for deployment. Many teams block deploying releases older than a defined age or with known exploited findings.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new advisory changes the status of a component that was clean when it shipped.
Safeguard offers continuous SBOM and dependency scanning, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a database migration reversible by rolling back code?
Not always. Design migrations to be backward compatible, or the rollback will break data access even if the code is safe.
Should we block old releases from redeploying?
Many teams do for releases with known exploited findings. Decide the rule in advance.
Sources
Last reviewed: 19 October 2026.
