A system counts as patched when the fixed code is running in production and you have checked it. Installed is not enough for an OS patch that needs a restart, and merged is not enough for a dependency update that needs a deploy. Define done as running and verified.
Installed, running, verified
Three states get mixed up.
| State | OS patch | Dependency update |
|---|---|---|
| Available | Vendor released update | Fixed version published |
| Applied | Package installed | Pull request merged |
| Running | Restart finished, new kernel or service loaded | New build deployed and serving traffic |
| Verified | Version query or scan confirms | Deployed artifact shows fixed version |
Only the last two rows reduce risk. A host with the update installed but an old process in memory is still running the old code.
Why OS patches stall at "installed"
Ubuntu's automatic update service installs security updates daily by default, but automatic reboot is off by default. Updates that need a restart may then wait for someone to do it. For services, a library update may need a service restart to load the new copy. See how to find services that need a restart after a library update and kernel livepatch: what it fixes.
Why dependency updates stall at "merged"
The pull request lands, but the service deploys next week, or an image is not rebuilt, or a long lived worker never restarts. The repository says fixed. Production says otherwise.
A done checklist
For an OS patch:
- Update installed on all hosts in the group.
- Restart completed where required.
- Version query or scan shows the fixed package.
- Exceptions logged with owner and date.
For a dependency update:
- Pull request merged with the lockfile change.
- New build produced from that commit.
- Deployed to every environment that carried the vulnerable version.
- Scan of the deployed artifact shows the fixed version.
Measure it honestly
Report the share of assets in each state, not one "patched" percentage. A big gap between applied and running is a finding in itself. NIST encourages choosing actionable patching metrics suited to each audience, which this split supports. More ideas: patch metrics that show risk.
Where Safeguard fits
Safeguard's continuous monitoring and scanning can check what is deployed against known vulnerabilities, so you can confirm the fixed version is the one running. See also your lockfile and your artifact disagree.
Quick check
Is a clean scan of the repository proof of a patch?
It proves the source is clean. Scan the deployed artifact to prove production is.
Does a container rebuild count as a restart?
Rebuilding creates a new image. The fix is running only after the new image is deployed and old containers are replaced.
Sources
Last reviewed: 19 October 2026.
