A team that deploys daily can patch dependencies continuously through normal releases, and keep a monthly rhythm for hosts that need restarts. The mistake is forcing one cadence on both layers. Match each one to how its change actually ships, and add an emergency lane for both.
Cadence by layer
| Layer | Natural cadence | Why |
|---|---|---|
| Application dependencies | Continuous, reviewed weekly | Ships with any deploy, per service |
| Container base image | Weekly rebuild | Docker advises rebuilding regularly |
| Host OS | Monthly cycle plus emergency lane | Restarts affect shared capacity |
| CI and build tooling | Monthly | Low urgency, high leverage |
The operating system rhythm
Microsoft notes that quality updates are typically released on the second Tuesday of each month, though they can be released at any time. Many teams anchor a monthly cycle to that date for Windows fleets, test in a pilot ring in the first week, and widen after. Linux distributions publish security updates on their own schedules, and Ubuntu's updater checks daily by default.
Pick a cycle you can keep. A monthly cycle with an emergency lane beats a weekly cycle you skip.
The dependency rhythm
When every merge deploys, a patched library is one pull request from production. Keep the flow short:
- A bot opens pull requests on a schedule you choose.
- Grouped updates cover routine bumps. Security updates arrive separately as alerts fire.
- CI runs tests and policy checks.
- A reviewer approves, and the next deploy ships it.
- Weekly, someone checks what has been open too long.
Avoid collisions
Do not stack a host restart window on top of a big release day. Publish one calendar showing the OS cycle, planned freezes and the weekly image rebuild. If you use release freezes, see pause dependency updates before a release freeze.
Add the emergency lane
Both layers need a path that skips the calendar. NIST SP 800-40 Rev. 4 describes emergency patching as the same approach on a highly accelerated schedule. Define the trigger in advance, such as active exploitation of something you run, and who may invoke it.
Measure the right thing
Track time from fix available to fix running, per layer. A daily deploy team with a three week dependency lag has a process problem, not a tooling one. See dependency update lag as an exposure metric.
Where Safeguard fits
Safeguard's policies, gates and guardrails can run on every pull request, so continuous patching has a continuous check. Fix PRs are available, off by default with every category on Manual.
Quick check
Should hosts also patch continuously?
Where you can replace nodes from a fresh image, yes. Where hosts are long lived and restart sensitive, a monthly cycle fits better.
Is a weekly image rebuild enough?
For routine cases, often. Trigger an extra rebuild when a serious base image advisory lands.
Sources
- Microsoft Learn: Windows Update client policies
- Docker Docs: Building best practices
- Ubuntu Server documentation: automatic updates
- NIST SP 800-40 Rev. 4 full text
Last reviewed: 19 October 2026.
