An OS patch is rolled back by restoring a snapshot, uninstalling the update or redeploying an earlier image. A dependency update is rolled back by reverting the lockfile change and redeploying. The dependency path is usually faster, but only if you kept the old lockfile and the old build is reproducible.
Side by side
| Factor | OS patch rollback | Dependency rollback |
|---|---|---|
| Mechanism | Snapshot restore, uninstall, image revert | Git revert of manifest and lockfile |
| Typical speed | Minutes to hours, restart often needed | Minutes, one deploy |
| Prerequisite | Snapshot, previous image, or uninstall support | Committed lockfile, reproducible build |
| Blast radius | Whole host or fleet group | One service |
| Hidden risk | Rolling back reopens the vulnerability on every host | Same, for one service |
| Data concern | Disk state changes since the snapshot | Data written by the new version |
Prepare before you patch
For OS patches, decide the method in advance. Snapshots work for virtual machines. Immutable images work for containers and golden image setups: you redeploy the previous image tag or digest. Some updates cannot be cleanly uninstalled, so do not assume it.
For dependencies, the npm documentation notes that committing the lockfile lets you return to earlier node_modules states without committing the directory itself. Other ecosystems have equivalents. The principle is the same: the lockfile in version control is your rollback point. See what is a lockfile and why commit it.
A rollback runbook in five steps
- Define the trigger. Which metric, how long, who decides.
- Name the target. The previous image digest or the previous lockfile commit.
- Execute. Redeploy, or revert and redeploy.
- Verify. Health checks and the same metrics that triggered the rollback.
- Record the exposure. You are now running the vulnerable version again. Log it as a time limited exception with an owner.
NIST describes emergency mitigation as an option when a patch is flawed or disrupts other systems, and says mitigations should be replaced by permanent fixes with enforced schedules. That is the right frame: a rollback is a temporary state, not a conclusion.
Choose a mitigation while rolled back
If the vulnerability is exploitable, a rollback leaves you exposed. Consider a short term mitigation: disable the affected feature, restrict network access, or add a filtering rule. Emergency mitigation when no patch exists yet lists options.
Common mistakes
- Reverting the manifest but not the lockfile, so the resolver picks the new version again.
- Rolling back one service when a shared library change affected several.
- Forgetting to pause the update bot, which reopens the same pull request.
Where Safeguard fits
Safeguard's fix PRs are ordinary pull requests, which means a rollback is an ordinary revert. Autonomous remediation is off by default. Related: rollback plan for an emergency patch.
Quick check
Should I roll back or fix forward?
If users are affected now and a clean rollback exists, roll back, add a mitigation, then fix forward when ready. If rollback is risky, fix forward fast.
How long can a rolled back vulnerable version stay?
Set an expiry when you record the exception. Review it against your patch policy and the severity of the issue.
Sources
Last reviewed: 19 October 2026.
