Most successful attacks on servers do not use clever new techniques. They exploit known vulnerabilities for which a fix was published weeks, months or even years earlier. Patch management, the routine of finding, testing and applying software updates, closes those doors. The challenge is doing it safely: an update that breaks your application at 11 a.m. on a busy day can feel worse than the risk it removed. This guide sets out a process that balances the two.
Why patch management gets neglected
Teams usually know they should patch. It slips because of fear of breakage, lack of a test environment, no agreed maintenance window, or simply because nobody owns the task. A written process with an owner fixes most of these. Unsupported software is the other trap: once an operating system or runtime reaches end of life, no further patches arrive, however diligent you are.
Step 1: Know what you are running
You cannot patch what you do not know exists. Maintain an inventory listing for each server:
- Operating system and version, and its end-of-life date.
- Major software: web server, database, PHP/Node.js/Python/Java runtime, control panel.
- Application dependencies: CMS core, plugins, themes, libraries managed by Composer, npm or pip.
- Firmware and hypervisor versions for physical hosts.
- Who owns the server and how critical it is.
Patching the OS but ignoring a WordPress plugin or an npm library leaves a large gap; application-level dependencies are a frequent route in.
Step 2: Prioritise by risk
Not every update is urgent. Classify them:
| Category | Example | Suggested timing |
|---|---|---|
| Critical, actively exploited, internet-facing | Remote code execution in your web server or CMS | Within 24-48 hours, emergency change if needed |
| High severity security | Privilege escalation in the kernel | Within a week |
| Medium/low security | Local information disclosure | Next regular maintenance window |
| Bug fixes and features | Minor version updates | Regular cycle, after testing |
| Major version upgrades | PHP 8.2 to 8.4, new OS release | Planned project with full testing |
Useful signals include the vendor's severity rating, the CVSS score, whether the component is exposed to the internet, and whether the vulnerability appears in CISA's Known Exploited Vulnerabilities catalog. Subscribe to security announcement lists for your distribution and key software.
Step 3: Automate routine security updates
For most servers, automatic installation of security updates from the distribution's official repositories is safer than waiting for a human. Distribution security updates are typically backported fixes designed not to change behaviour.
On Debian and Ubuntu, unattended-upgrades handles this. Confirm the security origin is enabled in /etc/apt/apt.conf.d/50unattended-upgrades, then turn it on:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
# Dry run to see what it would do
sudo unattended-upgrade --dry-run --debugOn RHEL, AlmaLinux and Rocky Linux, use dnf-automatic with upgrade_type = security and apply_updates = yes in /etc/dnf/automatic.conf:
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timerExclude packages that need careful handling, such as the database server or packages pinned for compatibility, and update those manually in a window.
Step 4: Test before broad rollout
For non-routine updates, follow a staged approach:
- Staging first: apply to a staging server that mirrors production and run your key business tests.
- Canary: update one production server (or a low-risk one) and watch error rates and logs.
- Roll out to the rest, one at a time behind a load balancer where possible.
If you have no staging environment, a snapshot of the production VM restored to an isolated network can serve as a temporary test bed.
Step 5: Handle reboots and service restarts
Kernel, glibc and OpenSSL updates do not fully take effect until the server reboots or affected services restart. Check what needs attention:
# Debian/Ubuntu
cat /var/run/reboot-required.pkgs 2>/dev/null
sudo needrestart -r l # list services needing restart
# RHEL family
sudo dnf needs-restarting -r # is a reboot required?
sudo dnf needs-restarting -s # which services need restartingSchedule reboots in an agreed maintenance window. Live kernel patching services (such as Ubuntu Livepatch or kpatch on RHEL) can apply some critical kernel fixes without a reboot, which helps when downtime is very costly, but you still need periodic reboots.
Step 6: Always have a way back
- Take a VM snapshot or confirm a fresh backup before significant updates.
- Know how to downgrade a package:
sudo apt install package=versionorsudo dnf downgrade package;dnf history undocan reverse a whole transaction. - For application dependencies, commit lock files (
composer.lock,package-lock.json) so you can redeploy the previous known-good set. - Decide in advance how long you will troubleshoot before rolling back.
Step 7: Verify and record
After patching, confirm services are running, the website responds, and error logs are quiet. A quick external check with our HTTP header checker confirms the site returns a 200 status and shows what server headers it exposes. Record what was patched, when and by whom; this log is invaluable for audits and for answering "what changed?" during incidents.
Measure how you are doing
Track a few simple figures: the number of servers with pending security updates, the age of the oldest pending critical patch, and the number of servers on unsupported software. If these trend upward, the process needs attention or more resources. Many businesses hand this routine to a server management provider so it happens consistently.
Key takeaways
- Patch management starts with an inventory that includes application dependencies and end-of-life dates.
- Prioritise by severity and exposure; critical internet-facing flaws need action within days.
- Automate distribution security updates, and stage riskier updates through testing and canaries.
- Plan reboots, keep a rollback path, verify afterwards, and log every change.