Patch Management

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

Patching is where vulnerability management turns findings into fixes — and it's operationally hard, because the same patch that closes a critical vuln can break production. Teams swing between patching too slowly (leaving known-exploited holes open) and patching recklessly (causing outages). This skill covers a patch process that's reliable, timely, and safe, plus what to do for the vulns you can't simply patch.

When to use it

The remediation engine of a vuln-management programme, and the response to the majority of findings (most vulnerabilities are fixed by applying a vendor patch). It executes the priorities that triage and prioritisation set.

Procedure

1. Patch on a risk-based cadence, not a flat schedule. The prioritisation work (severity × exposure × exploitation likelihood — cvss-in-context, EPSS, KEV) sets the urgency: actively-exploited/internet-facing gets an emergency patch in days; routine issues follow the normal monthly cycle. One-size timing either leaves critical holes open or churns on trivia.
2. Test before broad deployment. A patch can break applications. Deploy to a test/canary environment (or a small ring of hosts) first, confirm nothing breaks, then roll out in stages. This is the balance between speed and safety — staged rollout catches a bad patch before it takes down the fleet.
3. Automate deployment through patch-management/config tooling so patching is consistent and scalable, not a manual per-host chore that silently misses systems. Coverage gaps in patching are where unpatched, exploited hosts survive.
4. Handle emergency patches separately. For a KEV-listed or actively-exploited vuln on an exposed asset, the normal cycle is too slow — have an expedited path (accelerated testing, out-of-band deployment) with the risk of moving fast explicitly weighed against the risk of the open vuln.
5. Know what you can't patch, and mitigate it. Some systems can't be patched immediately — legacy/EOL software, OT/IoT, a patch that breaks a critical dependency, a system with no maintenance window. For these, apply compensating controls (segmentation, virtual patching/WAF/IPS rules, access restriction, monitoring) and document the residual risk rather than leaving it silently open.
6. Verify the patch actually applied — deployment reported success isn't the same as the vulnerability being closed (a patch that needs a reboot to take effect, a partial rollout). Confirm via rescan (see the remediation-verification skill).
7. Track patch coverage and timeliness as programme metrics — what percentage of systems are patched, and how fast, feeds reporting and shows whether the process works.

Cheatsheet

cadence = risk-based, not flat
  KEV / actively-exploited / internet-facing  -> emergency (days), expedited path
  routine                                      -> normal cycle (e.g. monthly)

safe rollout (speed vs stability)
  test/canary -> small ring -> staged fleet    (catch a bad patch before fleet-wide)
  automate deployment (consistency + coverage; manual = silently-missed hosts)

can't patch? -> COMPENSATING CONTROLS + documented residual risk
  legacy/EOL, OT/IoT, patch breaks a dependency, no maintenance window
  mitigations: segmentation | virtual patching (WAF/IPS) | access restriction | monitoring

verify: deployment "success" != vuln closed -> rescan to confirm (reboot? partial?)
track: patch coverage % + timeliness -> programme metrics

Reading the process

• Flat-schedule patching (everything monthly, no expedited path) = actively-exploited criticals sit open for weeks. Add a risk-based emergency track.
• No testing before broad rollout = a bad patch takes down production, which teaches the org to patch slowly — the worst outcome. Stage it.
• Manual, per-host patching = inconsistent coverage; the missed hosts are exactly where unpatched vulns survive. Automate.
• Unpatchable systems left silently open = known holes with no mitigation and no owner-decision; apply compensating controls and document the residual risk instead.
• "Deployed" but the vuln still shows on rescan = the patch didn't take effect (pending reboot, partial rollout); deployment success isn't remediation. Verify.
• Risk-based cadence, staged/automated rollout, mitigations for the unpatchable, verified by rescan = a working patch process.

The fix / best practice

• Set patch SLAs by risk — fast for exploited/exposed, normal for routine — so urgency matches reality (ties into risk-acceptance-and-sla).
• Test then stage deployments (canary → rings → fleet) to balance speed against stability and catch bad patches early.
• Automate patch deployment for consistent, complete coverage.
• Maintain an emergency-patch path for KEV/actively-exploited issues.
• Mitigate what you can't patch with compensating controls and record the residual risk (rather than leaving it open or pretending it's fixed).
• Verify by rescan that patches closed the vuln, and track coverage and timeliness as metrics.

Pitfalls

• Patching too slow (or too flat). Waiting for the monthly cycle to fix an actively-exploited internet-facing bug is how breaches happen. Risk-based urgency with an emergency path.
• Patching recklessly. No testing means a bad patch causes an outage — and the org's reaction is to patch slower. Stage rollouts.
• Assuming "deployed" = "fixed". Pending reboots and partial rollouts leave the vuln open despite a success report. Rescan to verify.
• Ignoring the unpatchable. Legacy/OT/EOL systems that can't be patched need compensating controls and documented risk, not silence.
• Manual patching at scale. It misses systems inconsistently; those gaps are unmonitored, unpatched risk.

References

• NIST SP 800-40 Rev 4 (Guide to Enterprise Patch Management Planning)
• The cvss-in-context, epss-and-exploit-likelihood, kev-catalog-workflow, risk-acceptance-and-sla, and remediation-verification skills
• CIS Controls — continuous vulnerability management

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.