# Patch Management > Use when building a patch process that actually closes vulnerabilities — rolling fixes out reliably and on time without breaking production, and knowing when you can't patch. - Skill: `jihedbfr-art/patch-management` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/patch-management` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/patch-management/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/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.