Vulnerability Management and Patching

Key Control Areas

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.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.