When artifacts are immutable, you cannot repair a bad version in place. You have two moves. Roll back by redeploying the previous known good digest, or roll forward by publishing a new version with the fix. Roll back when the old version is safe and the fix is not ready. Roll forward when the old version is also affected.
Why you cannot edit the bad release
Public registries are built so a published version stays the same. Maven Central says it does not remove or modify components once available and recommends publishing a new release with the fix, ideally a patch release under semantic versioning. npm says a name and version can never be reused, even after unpublish. Treat your internal registry the same way. See can you overwrite a published package version.
A decision table
| Situation | Better move | Reason |
|---|---|---|
| Regression, previous version is clean | Roll back | Fastest, least change |
| The vulnerability exists in the previous version too | Roll forward | Going back keeps the exposure |
| Database or schema change already applied | Roll forward, usually | The old code may not read the new data |
| Fix is a one line change and tested | Roll forward | Shorter exposure than a long rollback |
| Bad release contained a leaked secret | Rotate the secret, then roll forward | Rolling back does not remove the secret from circulation |
Database changes deserve their own care: see expand and contract migrations.
Steps for a rollback
- Identify the last good digest from your release records, not from a moving tag.
- Check that version against current advisories before you return to it. A version that was clean at release may not be clean today.
- Redeploy by digest.
- Confirm the running digest matches.
- Mark the bad version as withdrawn where the registry supports deprecation, so nobody installs it fresh.
Steps for a roll forward
- Fix on a branch from the bad commit or from the main line, with a test that fails on the bug.
- Build once, scan the new digest, and run it through the same gates as any release.
- Publish a new version number. Never reuse the old one.
- Promote the same artifact through environments.
- Announce which version supersedes which and why.
Prepare before you need it
Keep the previous two release digests available and not eligible for cleanup. Keep deploy by digest as the norm. Make sure a rollback has been rehearsed at least once. A policy of small releases makes either move easier because less changes at once.
Safeguard's continuous monitoring keeps checking released versions against new advisories, which tells you whether the version you plan to roll back to is still safe.
Quick check
Can I roll back to any old version?
Only if it is still safe. Check it against current advisories first, since new vulnerabilities may have been published after its release.
Does a rollback remove a leaked secret?
No. Anyone who already has the bad version keeps it. Rotate the secret.
Sources
Last reviewed: 19 October 2026.
