Patch Management: A Practical Guide for Modern Stacks

What patch management is

Patch management is the process of acquiring, testing, and deploying updates that fix security flaws and bugs across everything you run: operating systems, applications, the open-source dependencies your code pulls in, container base images, and firmware. If vulnerability management is the program that decides what needs fixing, patch management is the machinery that doesthe fixing — a repeatable pipeline from “a fix exists” to “the fix is running in production.”

The reason it deserves its own process is that patching is where good intentions meet operational reality. A patch can break a dependency, require a restart, or need a maintenance window. Without a structured approach, urgent fixes get deferred and routine ones pile into an unmanageable backlog. A defined lifecycle keeps both moving.

The patch management lifecycle

The steps are consistent across frameworks even when the names differ:

• 1. Inventory. Know what software and versions you run. You cannot patch what you have not catalogued.
• 2. Monitor. Watch vendor advisories, distribution security trackers, and your own scan output for available fixes.
• 3. Assess and prioritize. Not every patch is urgent. Rank by real risk before scheduling work.
• 4. Test. Apply the patch in staging first to catch regressions and compatibility breaks.
• 5. Deploy. Roll out through a controlled process — canary or staged — rather than all at once.
• 6. Verify. Re-scan or check versions to confirm the patch actually applied everywhere it should have.
• 7. Document. Record what changed, when, and why, for audit and for the next incident.

This loop runs on a cadence for routine updates and on demand for emergencies, which is the distinction the next section addresses.

Scheduled vs emergency patches

Much of patching is predictable. Many vendors ship on a regular cadence — Microsoft's Patch Tuesday, the second Tuesday of each month, is the best-known example — so teams can plan maintenance windows around a known rhythm. Predictability is a feature: it lets you batch testing and reduce the disruption of frequent restarts.

But a critical, actively exploited flaw does not wait for the calendar. Those trigger out-of-bandemergency patches, released outside the normal schedule, and your process needs a fast lane for them: abbreviated testing, an expedited change approval, and a rollback plan. The signal that a flaw belongs in that fast lane usually comes from exploitation data — a CVE landing in the CISA Known Exploited Vulnerabilities catalog is a strong cue to skip the queue.

Prioritizing what to patch first

You will never patch everything at once, so patching order is a risk decision. The same signals that drive vulnerability triage apply here: severity as a baseline, but weighted by exploit probability and real exposure. A patch that closes a flaw with a high EPSS exploit-probability score on an internet-facing service outranks a higher-severity patch for something isolated and unreachable. Asset criticality, whether the vulnerable path is actually used, and any compensating controls all feed the order.

Sometimes there is simply no patch to apply — the maintainer has not shipped a fix, or the fix would break you. That is not a dead end; it is a case for a documented mitigation and an accepted-risk decision, which we cover in prioritize vulnerabilities with EPSS.

Containers change the model

Traditional patch management updates a running system in place with a package manager. For containers, that instinct is wrong. Container images are immutable: patching a live container is throwaway work that vanishes on the next deploy and leaves your image definition still vulnerable. The correct model is rebuild-and-redeploy — you fix the recipe, not the running instance.

In practice that means updating the base image tag or dependency, rebuilding with a fresh pull so you actually pick up the patched layers, and redeploying the new image:

# rebuild WITHOUT the cache so updated base layers are pulled
docker build --pull --no-cache -t registry.example.com/app:1.4.2 .

# push the rebuilt image and roll it out
docker push registry.example.com/app:1.4.2
kubectl set image deployment/app app=registry.example.com/app:1.4.2

The --pull flag matters: without it, a cached base layer can silently keep an old, vulnerable version around even though the upstream tag has been patched. Our step-by-step guide to reducing CVEs in Docker images covers the full workflow, and automating base image updates shows how to make the rebuild happen on a schedule rather than by memory.

Verifying a patch actually landed

The step teams skip most often is verification. Deploying a patch and assuming it worked is how a “fixed” CVE reappears in the next audit. A cached layer, a pinned transitive dependency, or a rollout that only reached part of the fleet can all leave the vulnerable version running. The fix is to close the loop: re-scan the rebuilt artifact and confirm the package version moved. This is exactly the verification stage of the wider remediation cycle, and it is where an artifact scanner earns its place.

Where ScanRook fits

ScanRook sits at both ends of the patch loop. Before you patch, it tells you what needs patching: it reads the packages actually installed in a container image, source tree, or binary — not a guess from filenames — and cross-references each against OSV, NVD, and Red Hat OVAL, with EPSS and KEV signals attached so you can order the work by real risk. Because it reads installed state, it also understands backported fixes, so it will not flag a Red Hat package as vulnerable when the distribution has already patched it behind an unchanged version number, a nuance we explain in how to reduce CVEs in Docker images.

After you patch, re-running ScanRook against the rebuilt image is the verification step: the package that was flagged should be gone, and if it is not, you learn that immediately rather than at the next review. That before-and-after loop — scan, rebuild, scan again — is what turns patch management from a hopeful deploy into a confirmed fix.

Frequently asked questions