Patch Management

Every unpatched system is a countdown timer. The moment a vulnerability becomes public, attackers start scanning for systems that haven't been fixed. The patch exists. The vulnerability is known. The only question is whether you'll deploy the fix before someone exploits it.

This is patch management: the systematic process of finding, testing, and deploying software updates before the window of vulnerability becomes a breach.

The Race You're Already In

When a vulnerability is disclosed, a clock starts. Attackers reverse-engineer the patch to understand exactly what was wrong. They build exploits. They scan the Internet for systems still vulnerable.

You're racing them. And they have advantages—they don't need to test whether their exploit breaks your applications. They don't need change management approval. They just need one unpatched system.

The Equifax breach exposed 147 million people's personal data. The vulnerability had been patched two months earlier. WannaCry ransomware paralyzed hospitals and businesses worldwide, exploiting a Windows vulnerability Microsoft had fixed months before. These weren't sophisticated attacks against unknown vulnerabilities. They were straightforward exploitation of systems that simply hadn't been updated.

Having patches available means nothing. Deploying them is everything.

The Uncomfortable Tradeoff

Here's the tension that makes patch management genuinely hard: patches sometimes break things.

A security patch might conflict with your application. A firmware update might brick your network equipment. An OS update might introduce performance problems that take down your service.

So you face a choice: deploy immediately and risk breaking production, or test thoroughly and stay vulnerable longer. Neither option is safe. You're choosing between "definitely vulnerable now" and "might be broken soon."

This is why patch management is a discipline, not just a task. It requires systems for making these tradeoffs intelligently, not eliminating them.

How Patching Actually Works

Discovery is knowing what needs patching. You monitor vendor security bulletins, subscribe to vulnerability databases, and run tools that scan your systems for missing patches. You can't fix what you don't know about.

Assessment is triage. Not all patches are equal. A critical vulnerability in your Internet-facing web server needs immediate attention. A minor bug fix for an internal tool can wait. You're constantly asking: How severe? How exposed? How likely to be exploited? What breaks if we patch—and what breaks if we don't?

Testing catches patch problems before production. You deploy to environments that mirror production, verify the vulnerability is actually fixed, confirm applications still work, and watch for new issues. Good testing prevents patch-induced outages. But testing takes time you might not have.

Deployment gets patches onto production systems. This might mean maintenance windows, phased rollouts, or emergency changes outside normal procedures. The goal is consistent, reliable deployment—every system updated, no exceptions.

Verification confirms patches took. Did they install correctly? Are systems healthy afterward? Is the vulnerability actually closed?

Prioritization Under Pressure

When you have fifty patches to deploy and limited maintenance windows, prioritization determines what gets fixed first.

Actively exploited vulnerabilities get patched immediately, even if it means emergency changes. If attackers are using this vulnerability right now, waiting for a maintenance window is gambling with your systems.

Critical vulnerabilities without active exploitation get patched within days. These will likely be exploited soon. Don't let your systems be the ones still vulnerable when the attacks start.

High-severity patches for internal systems can often wait for scheduled windows. The exposure is lower, so the urgency is lower.

Minor fixes and improvements bundle into regular update cycles.

Exposure matters as much as severity. A medium-severity vulnerability in your public-facing API might be more urgent than a critical vulnerability in an isolated internal system that only three people can access.

When You Can't Patch

Sometimes you can't deploy a patch. The application breaks. The vendor no longer supports your version. The maintenance window is weeks away and the business can't tolerate downtime.

You're still responsible for the risk. Compensating controls become essential:

Virtual patching uses your web application firewall or intrusion prevention system to block exploitation attempts. The vulnerability exists, but attacks against it get stopped at the perimeter.

Network restrictions limit who can reach the vulnerable system. If only trusted internal systems can connect, the attack surface shrinks dramatically.

Enhanced monitoring watches for signs of exploitation. You might not be able to prevent the attack, but you can detect it quickly.

Isolation puts vulnerable systems on restricted networks until they can be patched or replaced.

Document why the patch isn't deployed and what controls are in place instead. When auditors or incident responders ask, you need answers.

The Tool Question

Manual patching doesn't scale. Beyond a handful of systems, you need automation.

The specific tools matter less than what they enable: knowing what patches are missing across your environment, deploying patches consistently without manual intervention, verifying deployment succeeded, and reporting on patch status for compliance and security.

Windows environments typically use WSUS, SCCM, or Intune. Linux shops use Satellite, Landscape, or configuration management tools like Ansible. Cloud infrastructure has native patching through services like AWS Systems Manager.

The right tool depends on your environment. The requirement for tooling is universal.

Different Systems, Different Challenges

Workstations patch frequently, often automatically. Users tolerate reboots. Individual machine problems are manageable. Automatic updates make sense here.

Servers need more care. Reboots affect services. Patches deploy during maintenance windows, often phased across server groups to maintain availability. Testing is rigorous.

Network infrastructure—routers, switches, firewalls—carries high risk. Updates often require downtime. Problems can take down entire network segments. These get extensive testing and careful scheduling.

Legacy systems might not receive patches at all. Vendors stop supporting old versions. You're left with systems that can't be fixed, only protected through network isolation and compensating controls.

Embedded and IoT devices often can't be patched in any practical way. Security depends on keeping them isolated and monitored.

Zero-Days: When There's Nothing to Deploy

Zero-day vulnerabilities are known and potentially exploited before patches exist. You're vulnerable with no fix available.

Patch management becomes about readiness: monitor for vendor announcements, have deployment processes ready to move fast when patches arrive, and use compensating controls in the meantime. Virtual patches, access restrictions, increased monitoring—everything you'd do when you can't patch, because you can't.

Zero-days are reminders that patching is essential but not sufficient. Defense requires multiple layers.

The Compliance Dimension

Regulations frequently mandate patch management. PCI DSS requires critical patches within one month. HIPAA expects procedures for software updates. Most security frameworks list patching as fundamental.

Compliance requires proof, not just action. You need records of what was patched, when, by whom, and what testing was done. Exceptions need documentation and compensating controls. Regular reporting demonstrates your program is working.

This isn't bureaucracy for its own sake. When a breach occurs, investigators will ask about your patching. Having systematic processes with documentation is the difference between "we take security seriously" and "we had no idea what was running."