Freeze deploys for any service that might contain the bad version until you can prove it does not. Keep shipping for services your lockfiles and built artifacts clear. The decision should follow evidence about each service, not a blanket rule, and it needs a named owner and an end condition.
What a freeze is for
A freeze has one job: stop the compromised version from reaching more places while you scope the problem. Every build that runs install against an unpinned range during the window can pull the bad release again. Every deploy of an affected artifact widens what you have to clean up later.
A freeze does not fix anything by itself. It buys time to answer the question "which of our things contain it?" If you can answer that in minutes, a long freeze is mostly cost.
The three states of a service
Sort every service into one of three states as fast as you can.
| State | Evidence | Action |
|---|---|---|
| Affected | Lockfile or built artifact lists the bad version | Freeze, then remediate and rebuild |
| Unknown | No lockfile, unpinned range, or no artifact inventory | Freeze until you can inspect the artifact |
| Cleared | Lockfile and built artifact both show a safe version | Keep shipping, with extra checks on the pipeline |
The Unknown row is where teams lose the most time. A service that cannot show what it contains gets treated like an affected one, and that is the correct default.
A narrow freeze beats a broad one
Scope the freeze by what a pipeline can pull in, not by team.
- Pause automated dependency update pull requests and scheduled rebuilds, since these are the paths most likely to resolve a new version unattended.
- Block the bad version at your registry mirror or proxy if you have one, so a build fails loudly instead of installing it.
- Freeze deploys for Affected and Unknown services.
- Keep a hotfix lane open for Cleared services, with a second reviewer and a check that the lockfile did not change.
If your pipeline cannot block a single version, the fallback is a broader freeze. That gap belongs on the follow-up list.
Who decides, and when it ends
Name one decision owner before the incident. In many teams that is the incident commander, with release engineering executing. Write the end condition at the start: for example, all Affected services rebuilt and verified, and all Unknown services moved to Cleared or Affected.
Log the freeze with a time, a scope and a reason. When customers wait on a fix unrelated to the incident, the log is what lets you explain why a release was held or why it was allowed through.
Common mistakes
- Freezing everything for days because inventory is slow. Fix the inventory, not the schedule.
- Freezing deploys but leaving scheduled jobs and bots running.
- Lifting the freeze when the registry removes the package, though your caches and lockfiles may still hold it. See is a supply chain incident over when the registry removes the package.
- Forgetting to tell support and sales that releases are delayed.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a gate stops a change at review time, which is the control that lets a narrow freeze work.
Quick check
Do I need to freeze services that do not use the package?
Not if you can show it. A lockfile and a built artifact that both lack the bad version are good evidence. Without that evidence, treat the service as unknown.
Is a freeze the same as stopping all dependency updates?
No. Pausing update bots is one part of it. A freeze also covers deploys of affected services and scheduled rebuilds.
Safeguard can help with the inventory side of this work. SBOM and dependency scanning show where a package and version appear across your projects, and policies and gates can stop a flagged version at the pull request. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
