Yes. A rollback redeploys an older release, so any vulnerable dependency or code that fix removed returns with it. Before you roll back after an incident, check whether the target release has known issues, and consider rolling forward with a fix instead.
How rollback works in twelve-factor
The methodology says deployment tools typically offer release management, most notably the ability to roll back to a previous release. Every release has a unique ID, such as a timestamp or an incrementing number. Releases form an append-only ledger and cannot be changed once created, so any change makes a new release. A release is a build combined with config.
That is the strength and the trap. Rolling back is fast because the old release still exists exactly as it was. It is also exactly as it was: with the dependencies, and the flaws, it had then.
When rollback reintroduces risk
- A security fix is in the release you leave. Rolling back to before the fix reopens the hole.
- New advisories appeared since. The old release may contain a package that is now known to be vulnerable, although it was clean the day it shipped.
- Config changed. A release combines build and config. If config was rotated after an incident, the old release's config may hold revoked credentials, or the rollback may attach old values.
- Database changes are not reversible. A migration that dropped or reshaped data may leave the old code unable to run safely.
- Image tags moved. If you roll back by tag and the tag was reused, you may not get the build you expect. See immutable image tags.
Decision guide
| Situation | Better choice |
|---|---|
| New release has a functional bug, no security change in it | Roll back |
| New release contains the security fix and also a bug | Roll forward with a patch release, or disable the broken feature with a flag |
| Rollback target has a known critical advisory | Roll forward |
| Incident involving leaked credentials | Rotate first, then deploy; rollback alone does not revoke anything |
| Schema changed in an incompatible way | Roll forward or run a planned reverse migration |
Make rollback safe by design
- Keep a short list of releases that are approved rollback targets, and scan them again on a schedule.
- Store the SBOM with each release ID so you can check what a target contained.
- Deploy by digest, not by mutable tag. See image digests versus tags.
- Make migrations backward compatible in steps so old and new code can run together.
- Record who rolled back, when and why.
- Use feature flags for risky behavior so you can disable a feature without redeploying; see feature flag kill switch.
Ask one question first
Before pressing the button, ask: does the release I am returning to contain anything we have since learned is unsafe? If you have an SBOM per release, answering takes a minute. If not, assume the answer is unknown and prefer a forward fix.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the demo and look at how a fix is presented, then compare it with what a rollback would bring back.
Quick check
Is rolling back always the fastest fix?
Often, but not always. A small forward fix can be faster than untangling migrations, and it avoids reopening a fixed flaw.
Does rolling back undo a leaked credential?
No. Rotate the credential separately. Rolling back changes which code runs, not which secrets are valid.
How do I know if an old release is risky?
Check the SBOM stored for that release against current advisories, and see whether any security fix landed after it.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies for every build, and its zero-day discovery and continuous monitoring help you see when a package in an old release becomes known to be vulnerable. Autonomous remediation can open a fix pull request for a vulnerable dependency, off by default with every category on Manual. Try a free scan.
Sources
Last reviewed: 19 October 2026.
