Table of Contents
What is a Security Patch?
A security patch is a targeted software update that fixes one or more security vulnerabilities without delivering new functionality. It modifies executable files, libraries, configuration, or firmware to eliminate or reduce the exploitability of a known weakness.
Patches are released by software vendors in response to:
- Internally discovered bugs during development and testing
- Responsible disclosure reports from external security researchers
- Active exploitation discovered in the wild (emergency/hotfix patches)
- Government mandates (e.g., CISA KEV catalog requirements)
From the vendor's side, a patch usually involves changing source code to add input validation, fix memory handling, enforce proper access controls, or disable an unsafe feature, then compiling, signing, and distributing the update through official channels.
Types of Patches
| Patch Type | Description | Example |
|---|---|---|
| Security Patch | Fixes a security vulnerability specifically | Apache httpd 2.4.59 fixing CVE-2024-27316 |
| Hotfix | Emergency patch for an actively exploited critical vuln, released outside normal cycle | Microsoft out-of-band patch for a Defender zero-day |
| Bug Fix | Fixes non-security defects | Memory leak fix in database driver |
| Feature Update | Adds new functionality; may include security improvements | Major OS version update |
| Firmware Update | Patches hardware-level code (BIOS, UEFI, NIC firmware) | Intel microcode update for Spectre |
| Configuration Hardening | Not code — changes default settings to more secure values | Disabling TLS 1.0/1.1 via config |
Patch Tuesday
Patch Tuesday is the second Tuesday of each month, when Microsoft releases its batch of security updates. This predictable schedule lets IT teams plan maintenance windows around a known release date. Adobe, Intel, and SAP also align many releases to Patch Tuesday. Other vendors like Red Hat, Ubuntu, and Cisco have their own release schedules.
Why Patching Matters
The overwhelming majority of successful cyberattacks exploit known vulnerabilities — ones that already have patches available. A landmark Verizon Data Breach Investigations Report finding: over 80% of successful breaches exploited vulnerabilities for which patches had been available for more than a year.
Notable examples where slow patching led to catastrophe:
- WannaCry (2017) — Exploited EternalBlue (CVE-2017-0144) in Windows SMB. Microsoft had released patch MS17-010 two months earlier. Over 200,000 systems in 150 countries were infected because they had not been patched.
- Equifax breach (2017) — Apache Struts CVE-2017-5638 was patched in March 2017. Equifax was breached in May 2017 — two months after the patch was available — exposing 147 million records.
- Log4Shell (2021) — Apache released Log4j 2.15.0 within days. Organisations that delayed patching continued to face exploitation months later.
Patching SLAs: How Fast Should You Patch?
Most security frameworks define patching timeframes based on CVSS severity. These are common benchmarks:
| CVSS Severity | Score Range | CISA Mandate | Common Enterprise SLA |
|---|---|---|---|
| Critical | 9.0 – 10.0 | 15 days | 7–15 days |
| High | 7.0 – 8.9 | 30 days | 30 days |
| Medium | 4.0 – 6.9 | — | 60–90 days |
| Low | 0.1 – 3.9 | — | Next maintenance cycle |
| CISA KEV Listed | Any | Per KEV deadline (often 2 weeks) | Immediate |
If a vulnerability appears on the CISA Known Exploited Vulnerabilities (KEV) catalog, it means it is being actively exploited in the wild. Federal agencies are required by law to patch these within the specified deadline. Private organisations should treat KEV entries as highest priority regardless of CVSS score.
How to Apply Patches on Linux
The exact commands vary by Linux distribution, but the process is the same: update the package list, then install available updates.
Ubuntu / Debian
# Update package index
sudo apt update
# View available security updates
apt list --upgradable 2>/dev/null | grep -i security
# Apply all updates (including security)
sudo apt upgrade -y
# Apply security updates only (requires unattended-upgrades)
sudo unattended-upgrade --dry-run # preview
sudo unattended-upgrade # applyRHEL / CentOS / Rocky Linux (dnf/yum)
# List available security updates
sudo dnf check-update --security
# Apply security updates only
sudo dnf update --security -y
# Apply all updates
sudo dnf update -yCheck If Reboot Is Required
# Ubuntu/Debian
ls /var/run/reboot-required 2>/dev/null && echo "Reboot required"
# RHEL/CentOS
sudo needs-restarting -rneeds-restarting on RHEL or checkrestart on Debian to identify which services need restarting.Automated Security Patching on Linux
For servers, consider enabling unattended security updates to reduce the window between patch release and application:
# Ubuntu: install and enable
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
# Configuration file
cat /etc/apt/apt.conf.d/50unattended-upgrades
# Ensure "${distro_id}:${distro_codename}-security" is uncommentedHow to Apply Patches on Windows Server
Via Windows Update (GUI)
Or search "Windows Update" in the Start menu.
Windows will download and list available updates, flagging security updates separately.
Do not defer security updates. Click "Download and install" for Critical and Security updates immediately.
Many Windows patches require a restart. Schedule during a maintenance window.
Via PowerShell (Recommended for Servers)
# Install PSWindowsUpdate module if not present
Install-Module -Name PSWindowsUpdate -Force
# List available security updates
Get-WindowsUpdate -Category "Security Updates"
# Install all security updates
Install-WindowsUpdate -Category "Security Updates" -AcceptAll -AutoRebootEnterprise: WSUS and SCCM
For large environments, use Windows Server Update Services (WSUS) to centralise patch approval and deployment, or Microsoft Endpoint Configuration Manager (SCCM/MECM) for full lifecycle management including testing, approval workflows, and compliance reporting.
Patching Containers and Cloud Services
Containers and cloud-managed services require a different patching approach.
Container Images
Container images are immutable — you do not patch a running container. Instead:
- Rebuild the base image from a patched base (e.g.,
FROM ubuntu:24.04after Ubuntu releases security updates) - Run your CI/CD pipeline to test the new image
- Deploy the new image, replacing the old containers
Use tools like Trivy, Grype, or Snyk Container to scan images for vulnerabilities before deployment.
Cloud Managed Services
Cloud-managed databases (RDS, Cloud SQL), load balancers, and serverless functions are patched by the cloud provider automatically. Your responsibility is to check the provider's security bulletins and update configuration when required (e.g., moving to a newer engine version when an old version reaches end of life).
Patch Management Best Practices
- Maintain an asset inventory. You cannot patch what you do not know exists. Use tools like Qualys VMDR, Tenable.io, or open-source alternatives to discover and inventory all systems.
- Test before production. Apply patches to a staging environment first for non-critical systems. For critical-CVSS patches on internet-facing systems, the risk of not patching outweighs the risk of a patch breaking something.
- Prioritise using CVSS + CISA KEV. A CVSS 6.0 vulnerability that is on the KEV list and actively exploited is more urgent than a CVSS 8.0 that has no public exploit.
- Track patch status. Log which systems have been patched and when. This is required for SOC 2, PCI DSS, ISO 27001, and HIPAA audits.
- Automate where possible. Unattended upgrades on Linux, automatic Windows updates for workstations, Dependabot for open source dependencies.
- Address end-of-life software. Software past its end-of-life date no longer receives security patches. Upgrade or isolate EOL systems.
- Have a rollback plan. Take snapshots or backups before applying major patches so you can recover if a patch causes instability.