Dependency freeze in release week: are security overrides exempt?

Yes, but through a narrow path. A freeze exists to stop untested churn, so security fixes should be allowed only with a named approver, a minimal diff, and test evidence. Anything broader waits. Write this exemption into the freeze policy before the freeze starts.

Why this causes friction

Release managers want a stable tree. Security wants a known issue closed. Without a rule, the release manager says no, security escalates, and the loudest voice wins.

A written exemption removes the drama. Everyone knows what qualifies and what to bring.

What qualifies

Keep the criteria short and testable.

• A published advisory for a package that ships in the release.
• The vulnerable code is reachable, or the severity and exposure justify acting anyway.
• The smallest fix available: a single override or patch version, not a major upgrade.
• The change touches only the lockfile or override block, not application code.

What does not qualify

• Routine version updates, even if labeled as security hygiene.
• Major version jumps without a prior test cycle.
• Bundled changes where a security fix is attached to unrelated updates.
• Findings with no reachability or exposure case and a low urgency.

Those go into the first sprint after the release.

The exemption path

1. Request. Use the override template: package, version, reason, services affected, tests, owner.
2. Approver. The release manager and a security reviewer both sign. Two people prevent both rubber stamps and blanket refusals.
3. Evidence. Dependency tree diff, resolved version from the lockfile, passing tests for each affected service.
4. Isolation. Merge as its own change, so it can be reverted without touching anything else.
5. Watch. After deploy, monitor error rates for the affected service for an agreed window.

When the answer is no

Sometimes the fix is too risky for release week. Then record a dated exception with a compensating control. Examples include a configuration setting that disables the vulnerable feature, input restrictions at a gateway, or tighter network exposure. Set the review date for the first day after release.

A worked example

Suppose an advisory lands on Tuesday for a parsing library that the checkout service ships. Freeze began Monday. The service owner confirms the library is in the deployed image and that the vulnerable function handles uploaded files. A single override to the patch release in the same minor version exists.

The owner files the request with the tree diff, the resolved version, and a passing test run. The release manager and the security reviewer both sign within the day. The change merges alone, ships with the release candidate, and the owner watches error rates for two hours. Nothing else moved, so nothing else needs retesting.

Compare that with a second advisory the same week for a library used only by an internal report. It is not reachable from any public path, and the fix is a major version. That one goes on the post release list with a note.

Make the next freeze easier

Count how many exemptions were requested and how many were granted. If many were requested, the backlog of unpatched advisories before freeze is too large, and the fix is earlier, steadier updates. A freeze should not be the first time anyone looks at advisories in a month.

Quick check

Last reviewed: 19 October 2026.