Vulnerability Management and Patching

Key Control Areas

• Asset Discovery and Inventory Management (CM-08, CM-08(1), RA-05, PM-05, SA-09): You cannot patch what you cannot find. CM-08 mandates a system component inventory: every server, workstation, network device, container, cloud instance, and IoT device must be catalogued with its owner, classification, operating system, installed software, and network location. CM-08(1) requires automated discovery: tools that continuously scan the network for new devices, query cloud APIs for new instances, and monitor container orchestrators for new workloads, because manual inventory is always outdated. RA-05 requires that vulnerability scanning covers the complete inventory: every asset in the inventory must be scanned, and any asset discovered by the scanner but not in the inventory is an immediate finding. PM-05 tracks the information system inventory at the programme level: how many assets exist, what percentage are managed, what percentage are scanned, and what percentage are within patch compliance SLAs. SA-09 extends inventory to external services: SaaS platforms, cloud services, and third-party managed infrastructure that process corporate data have their own vulnerability profiles managed by the provider, but the organisation must verify that provider patching meets its requirements. The inventory problem is worse than most organisations admit: cloud auto-scaling creates ephemeral instances that exist for hours, container deployments spin up hundreds of instances from a single image, and shadow IT projects create systems that nobody in security knows about.
• Vulnerability Scanning and Detection (RA-05, SI-02, CA-07, SI-04, CM-06): Scanning is the engine. RA-05 mandates vulnerability monitoring and scanning: authenticated scans (with credentials that can check installed patch levels and configurations) running on a defined schedule -- weekly for critical assets, fortnightly for standard, monthly at minimum. Authenticated scanning is essential: unauthenticated scans miss 30-50% of vulnerabilities because they cannot see what is installed behind a firewall or login prompt. SI-02 identifies flaws that require remediation: the scanner output is the input to the remediation workflow. CA-07 provides continuous monitoring: moving beyond scheduled scans to continuous assessment using agents (Qualys, Tenable, Rapid7) that report vulnerability status in real time, detecting new vulnerabilities within hours of asset deployment or CVE publication. SI-04 feeds additional vulnerability intelligence from system monitoring: EDR agents detecting vulnerable software versions, network monitoring identifying systems running insecure protocols, and cloud security posture management detecting misconfigured services. CM-06 identifies configuration vulnerabilities that are not CVE-based: default credentials, unnecessary services, insecure protocol versions, and missing hardening settings that scanners detect through compliance benchmarks (CIS Benchmarks, DISA STIGs). Configuration vulnerabilities are often higher risk than software CVEs because they are trivial to exploit and never addressed by vendor patches.
• Risk-Based Prioritisation (RA-03, RA-05, PM-16, CA-02, RA-02): Not all vulnerabilities are equal. RA-03 assesses risk for each vulnerability in context: CVSS base score provides severity, but context determines actual risk. A CVSS 9.8 on an air-gapped test server is less urgent than a CVSS 7.5 on an internet-facing production system processing financial transactions. RA-05 incorporates threat intelligence: is this vulnerability being actively exploited in the wild (CISA KEV catalogue, vendor advisories, threat intelligence feeds)? Actively exploited vulnerabilities jump to the front of the queue regardless of CVSS score. PM-16 provides threat awareness from external sources: sector-specific threat intelligence (FS-ISAC for financial services, H-ISAC for healthcare) that identifies vulnerabilities being targeted in your industry. CA-02 assesses control effectiveness: compensating controls (WAF rules, network segmentation, endpoint protection) that reduce exploitability buy time for remediation without eliminating the vulnerability. RA-02 categorises assets by criticality: crown jewels (trading systems, payment systems, customer data stores) receive the tightest SLAs, while lower-criticality assets receive proportionally longer remediation windows. Effective prioritisation reduces actionable findings from tens of thousands to hundreds, making the queue manageable. Organisations that try to treat all vulnerabilities equally end up patching nothing effectively.
• Patch Management Lifecycle (SI-02, CM-03, CM-04, CM-02, SA-10): Patching is a change management discipline. SI-02 mandates flaw remediation within defined timeframes: SLAs based on risk rating (Critical: 48 hours for actively exploited/internet-facing, 7 days otherwise; High: 14 days; Medium: 30 days; Low: 90 days). CM-03 governs patch deployment through change management: every patch is a change that requires testing, approval, and rollback capability. Emergency patches (actively exploited critical vulnerabilities) use an expedited change process that compresses approval without eliminating it. CM-04 analyses security impact of patches: testing in non-production environments to identify application breakage, performance degradation, and dependency conflicts before production deployment. Test coverage must include the applications that run on the patched systems, not just the OS patch itself. CM-02 maintains baseline configurations: patched systems must match the approved baseline, and patching is an opportunity to detect and correct configuration drift. SA-10 manages software updates through the development pipeline: application dependency patches (library updates, framework patches) follow the SDLC process (SP-012) with automated SCA driving the remediation workflow. Patch deployment automation (WSUS, SCCM, Ansible, Chef, cloud-native patch managers) is essential for scale, but automation without testing creates its own risk -- a bad patch automatically deployed to 5,000 servers is worse than a manually deployed bad patch on 50.
• Exception Management and Risk Acceptance (RA-03, CA-02, PM-09, PL-02, CM-03): Not everything can be patched. RA-03 assesses residual risk when patching is not feasible: legacy systems that cannot accept patches (end-of-life software, embedded systems, OT environments), patches that break critical applications, and maintenance windows that are too infrequent for the SLA. CA-02 validates compensating controls for exceptions: network isolation, WAF rules, enhanced monitoring, application-layer mitigations, or virtual patching (IPS signatures that block exploit attempts). Every exception must be documented, approved by a risk owner at appropriate seniority, time-limited (maximum 90 days before re-review), and tracked in a risk register. PM-09 establishes the risk management strategy that defines acceptable residual risk: what level of vulnerability exposure is the organisation willing to accept, and who has authority to approve exceptions at each risk level. PL-02 documents exceptions in the system security plan. CM-03 ensures that exception expiry triggers re-evaluation: when an exception expires, the vulnerability must be remediated, the exception re-approved with updated justification, or the system decommissioned. The most dangerous exceptions are the ones that become permanent: a 'temporary' exception for a legacy system that nobody wants to decommission becomes a permanent unpatched exposure that everyone forgets about until it is exploited.
• Metrics, Reporting, and Governance (CA-07, PM-14, RA-05, AU-06, PM-05): Metrics drive behaviour. CA-07 provides continuous monitoring of vulnerability posture: dashboards showing current vulnerability counts by severity and age, patch compliance rates by asset group, and trend lines that indicate whether the programme is winning or losing. PM-14 reports to governance: monthly metrics to the security committee, quarterly metrics to the board risk committee, and immediate escalation when critical vulnerabilities exceed SLA. Key metrics include: mean-time-to-remediate (MTTR) by severity -- this is the single most important metric because it measures actual remediation speed, not just identification; patch compliance rate (percentage of assets within SLA); vulnerability density (vulnerabilities per asset, trending over time); scanner coverage (percentage of inventory scanned within the last cycle); exception count and age (how many vulnerabilities are in accepted-risk status and for how long); and re-open rate (vulnerabilities that were marked remediated but reappeared, indicating failed patching). RA-05 tracks scanning effectiveness: false positive rates, scan failure rates, and coverage gaps. AU-06 analyses vulnerability trends: are the same vulnerability types recurring (indicating systemic issues), are specific teams consistently failing SLAs (indicating resource or prioritisation problems), and are specific asset types chronically unpatched (indicating architectural problems). PM-05 provides programme-level metrics: total asset count, managed asset count, scan coverage, and overall risk posture trend.
• Automation and Tooling Integration (RA-05, SI-02, CM-03, CA-07, SA-09): Scale demands automation. RA-05 implements automated scanning: agent-based continuous assessment (Qualys, Tenable, Rapid7) that eliminates the lag between scheduled scans and provides real-time visibility. SI-02 automates remediation workflows: scanner findings automatically create tickets in ITSM (ServiceNow, Jira), assigned to the correct team based on asset ownership, with SLA timers and escalation rules. CM-03 integrates patch deployment with change management: automated patch deployment tools (WSUS, Intune, Ansible, AWS Systems Manager) that deploy approved patches within maintenance windows and report deployment status back to the vulnerability management platform. CA-07 provides automated compliance reporting: dashboards that pull data from scanners, CMDB, and patch management tools to show real-time posture without manual spreadsheet compilation. SA-09 monitors third-party vulnerability management: cloud provider security bulletins, SaaS vendor status pages, and managed service provider patch compliance reports integrated into the overall vulnerability view. The integration between vulnerability scanner, CMDB, ITSM, and patch management tools is the technical backbone of the programme: without integration, teams spend more time managing spreadsheets than remediating vulnerabilities.

When to Use

This pattern applies to every organisation that operates technology -- vulnerability management is not optional. It is particularly critical for: organisations with internet-facing systems where unpatched vulnerabilities are directly exploitable, regulated industries where vulnerability management is explicitly required (PCI DSS Requirement 6, DORA ICT risk management, FCA operational resilience), organisations with large and heterogeneous technology estates where manual tracking is impossible, organisations that have experienced breaches through unpatched vulnerabilities, environments running legacy or end-of-life systems that require formal exception management, organisations with cyber insurance that requires demonstrated vulnerability management capability, and any organisation that wants to reduce its attack surface systematically rather than reactively.

When NOT to Use

There are no contraindications for vulnerability management -- every organisation needs it. The scale and tooling varies: a five-person company can manage vulnerabilities through automated OS updates and a monthly manual review, while an enterprise needs a full scanning platform, ITSM integration, and a dedicated vulnerability management team. Organisations should not deploy vulnerability scanning without first establishing the remediation capability and process to act on findings -- scanning without remediation just produces expensive reports that document risk without reducing it.

Typical Challenges

The fundamental challenge is volume versus capacity: scanners find vulnerabilities faster than teams can remediate them, creating a backlog that grows over time and demoralises the teams responsible. Patching breaks things: every operations team has war stories of patches that caused outages, which creates institutional resistance to applying patches ('if it ain't broke, don't fix it'). Maintenance windows are scarce: 24/7 operations, global time zones, and change freezes around month-end, quarter-end, and peak trading periods leave narrow windows for patching. Legacy systems cannot be patched: end-of-life operating systems, embedded systems with no vendor support, and OT devices that were never designed for patching create permanent vulnerabilities that can only be mitigated, not fixed. Asset ownership is unclear: nobody claims ownership of the server that runs the legacy application that nobody understands but everyone depends on, which means nobody patches it. Scanner false positives erode trust: if 30% of findings are false positives, teams stop trusting the scanner and start ignoring all findings. Application dependency conflicts: patching the OS breaks the application, upgrading the framework requires code changes, and updating one library conflicts with another. Cloud and container environments change faster than scanning cycles: an ephemeral container may deploy, serve traffic, and terminate before the scanner runs. Metrics are gamed: teams mark vulnerabilities as 'remediated' by applying compensating controls that reduce the count without reducing the risk, or by decommissioning the scanner agent rather than patching the system.

Threat Resistance

Vulnerability Management directly reduces the attack surface that adversaries exploit. Known exploited vulnerabilities are remediated within aggressive SLAs, eliminating the entry points used by the majority of opportunistic attackers and many advanced persistent threats (RA-05, SI-02). Internet-facing vulnerabilities receive the tightest SLAs because they are directly accessible to any attacker globally (RA-05, SC-07). Ransomware initial access vectors -- commonly unpatched VPN appliances, Exchange servers, and web applications -- are prioritised through threat intelligence integration that highlights the CVEs being weaponised by ransomware operators (RA-05, PM-16). Supply chain vulnerabilities in third-party libraries are detected by SCA and remediated through dependency patching workflows (RA-05, SA-09). Configuration vulnerabilities (default credentials, unnecessary services, insecure protocols) that automated tools cannot detect through CVE scanning are identified through compliance benchmarks and remediated through configuration management (CM-06, CM-02). Zero-day vulnerabilities where no patch exists are mitigated through compensating controls (virtual patching, network isolation, enhanced monitoring) until vendor patches are available (CA-02, SC-07). The key metric is mean-time-to-remediate for actively exploited critical vulnerabilities: organisations that achieve 48-hour MTTR for this category eliminate the vast majority of vulnerability-based risk.

Assumptions

The organisation has a vulnerability scanning platform deployed or budgeted for. An IT asset management or CMDB capability exists or is being established. Change management processes exist for production systems. Maintenance windows are available for patching (even if limited). System owners are identified for the majority of the technology estate. IT operations teams have the skills and access to deploy patches. Management understands that vulnerability management is a permanent capability, not a one-time project.

Developing Areas

• EPSS (Exploit Prediction Scoring System) is emerging as a more actionable prioritisation signal than CVSS alone, predicting the probability of exploitation within 30 days based on real-world data. However, EPSS adoption remains below 15% of enterprises, and most vulnerability management platforms default to CVSS-based prioritisation. The combination of EPSS probability, CVSS severity, CISA KEV status, and asset criticality into a unified risk score is the direction of travel but lacks standardised methodology.
• VEX (Vulnerability Exploitability eXchange) promises to reduce false-positive noise by allowing software vendors to communicate whether a CVE actually affects their specific product version and configuration. Adoption is nascent -- fewer than 5% of vendors publish VEX documents -- but regulatory pressure (US Executive Order 14028, EU Cyber Resilience Act) is driving momentum. The challenge is operationalising VEX consumption: integrating vendor-published exploitability data into scanning platforms so that not-affected findings are automatically suppressed.
• Vulnerability prioritisation fatigue at scale is an increasingly recognised organisational failure mode. Enterprises with 50,000+ findings from continuous scanning report that triage meetings, ticket assignment, and remediation tracking consume more analyst time than actual remediation. Emerging approaches include autonomous remediation (auto-patching pre-approved categories), risk-based queue compression (reducing 50,000 findings to 500 actionable items), and SLA automation (auto-escalation without human triage), but each introduces new risks around unintended changes.
• Container and serverless vulnerability management fundamentally challenges traditional scanning models. Container images may be rebuilt from scratch daily, making point-in-time scanning irrelevant. Serverless functions have no persistent infrastructure to scan. The shift to scanning at build time (image scanning in CI/CD) rather than at runtime (agent-based scanning of deployed systems) is well understood but inconsistently implemented, with an estimated 40% of production container images deployed without any vulnerability scan.
• Coordinated vulnerability disclosure is under strain as the volume of discovered vulnerabilities increases and researcher-vendor relationships become more adversarial. The average time from vendor notification to patch availability remains 60-90 days for major software vendors, during which disclosed vulnerabilities may leak or be independently discovered by threat actors. Bug bounty platforms have professionalised disclosure but created new challenges around scope disputes, duplicate findings, and the economics of vulnerability hoarding versus responsible disclosure.