Patch management: from “update available” to verified fix

Every software update that says “security fixes” closes a door that someone has found open. Once a vulnerability is published, attackers study the fix to understand the flaw, and systems that stay unpatched become easy targets. CISA’s catalog of Known Exploited Vulnerabilities exists precisely because so many real attacks use flaws for which a patch was already available. Patch management is the routine that keeps that window as short as possible.

NIST’s guide to enterprise patch management (SP 800-40 Rev. 4) frames patching as preventive maintenance: an ordinary, planned cost of running technology, like servicing a car, rather than an emergency response. The organisations that patch well are the ones that turned it into a predictable routine.

1. Know what you run

The lifecycle starts with an inventory of hardware, operating systems and applications, including versions. Without it, forgotten machines and old apps stay unpatched forever. Vulnerability scans from the previous lesson help reveal what the inventory missed.

2. Identify what needs updating

Follow vendor security announcements (Apple publishes its security releases with the CVEs each update fixes), subscribe to advisories for the software you depend on, and compare your inventory with scan results. For each available update, note which vulnerabilities it closes and whether any are known to be exploited. Do not forget third-party software: browsers, plug-ins, developer tools and chat apps are frequent targets and often update separately from the operating system.

3. Prioritise and test

Not every update is equally urgent. Actively exploited flaws on internet-facing systems come first; many organisations set targets such as days for critical, exploited issues and weeks for the rest. Before a broad rollout, test updates on a small group of representative machines to catch incompatibilities with business software. Testing should be quick; a week of testing is not a reason to leave a known exploited hole open.

4. Deploy

Roll out in waves: the test group, then early adopters, then everyone. Use central tools where possible (device management for company Macs, automatic updates for personal devices). Schedule restarts sensibly, since many updates are not effective until the machine or app restarts, and communicate clearly so people do not postpone them indefinitely.

5. Verify

A patch is only done when it is confirmed. Re-scan or check versions to make sure the update actually installed everywhere, and investigate failures. Track simple metrics: how many machines are current, and how long critical fixes take from release to full deployment.

When you cannot patch: exceptions

Sometimes a system cannot be updated: a medical device approved only on an old version, a machine running software that breaks after upgrading, or a product the vendor no longer supports. These exceptions should be documented, approved by someone accountable, reviewed on a date, and protected with compensating controls:

• Isolate the system on its own network segment and block everything it does not strictly need.
• Remove internet access if the system does not need it.
• Disable the vulnerable feature or service if possible.
• Monitor it more closely, and plan its replacement.

On a Mac, a per-app firewall is a practical compensating control: an app you cannot update yet can be restricted to the servers it really needs, or blocked from the internet entirely, until the fix arrives.

Keeping a Mac current

1. Turn on automatic updates for macOS, including security responses and system files (System Settings › General › Software Update).
2. Update apps from the App Store automatically, and check apps from other sources through their own update menus.
3. Restart when asked: many fixes only apply after a restart.
4. Remove apps you no longer use; they are one less thing to patch.
5. Use a tool that tells you which apps are behind. FireAI’s “apps that need an update” list does this for well-known apps it has seen connecting.