Package update discipline - patching as a security control · Linux

Patches are the single most impactful security control. A known-vulnerable package with an available patch is a known-vulnerable host. The discipline: patch frequently, test before production, react to high-severity findings within hours.

The patch lifecycle

1. Vulnerability disclosed
2. CVE assigned
3. Distribution package released
4. Testing
5. Production deploy
6. Verification

The total time from step 1 to step 6 is the mean time to patch (MTTP). The goal: minimise MTTP for high-severity CVEs.

Patch frequency

Severity	MTTP target
Critical (RCE, auth bypass)	Hours to 1 day
High (privilege escalation, info disclosure)	Days to 1 week
Medium	Weeks
Low	Monthly or quarterly

Critical CVEs need emergency patching. High CVEs patch in the next regular cycle. Medium and low patch in batch.

Automated patching

For non-critical environments, unattended upgrades are acceptable:

# Debian/Ubuntu
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::AutoFixInterruptedDpkg true;
Unattended-Upgrade::MinimalSteps true;
Unattended-Upgrade::Remove-Unused-Kernel-Packages true;
Unattended-Upgrade::Remove-New-Unused-Dependencies true;
Unattended-Upgrade::Remove-Unused-Dependencies false;
Unattended-Upgrade::Automatic-Reboot false;

# /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

For RHEL family, use dnf-automatic:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

# /etc/dnf/automatic.conf
[commands]
upgrade_type = security
apply_updates = yes

Test before production

Critical patches should be tested in a non-production environment first:

# In staging
sudo apt upgrade -y

# Test critical services
sudo systemctl status nginx postgresql sshd

# Run application smoke tests
curl -I https://staging.example.com

If the staging tests pass, deploy to production with automation:

# Via configuration management
ansible-playbook -i prod update.yml

React to high-severity findings

Subscribe to security advisories for your distribution:

Ubuntu: https://ubuntu.com/security/notices
Debian: https://security-tracker.debian.org/
RHEL: https://access.redhat.com/security/security-updates/
SUSE: https://www.suse.com/support/security/

For high-severity CVEs:

Confirm the host is affected (check installed package version against the CVE).
Test the patch in staging.
Apply to production within the MTTP target.
Verify the vulnerability is fixed.

Track CVEs

# Debian/Ubuntu: pending updates, then the CVEs behind them
apt list --upgradable
sudo apt install debsecan
debsecan --suite bookworm --format detail
debsecan --suite bookworm --only-fixed --format packages

# RHEL family: pending security errata, then the CVE mapping
dnf check-update --security
dnf updateinfo list security
dnf updateinfo info --cve CVE-2024-3094

# Compliance scan (installed as the openscap-scanner package)
sudo oscap oval eval --results oval-results.xml com.redhat.rhsa-all.xml

debian-security-tracker and yum-plugin-security are not commands

The Debian security tracker is a web service (security-tracker.debian.org). There is no debian-security-tracker package and no command by that name, so apt install debian-security-tracker fails with E: Unable to locate package. The on-host tool that consumes the same data is debsecan, and --suite must name the release you are running (bookworm, trixie), because the fix state of a CVE is per-suite.

yum-plugin-security was a RHEL 6 plugin package, not a command. On RHEL 8 and 9 the functionality is built into dnf as the updateinfo subcommand and the --security flag. Typing the old plugin name gives you bash: yum-plugin-security: command not found, which reads as a broken host rather than the wrong instruction.

Both names appear in old runbooks. Correct them where you find them, because a patch runbook that fails at the first command gets abandoned mid-incident.

apt list --upgradable and dnf check-update --security match on repository metadata, so they list pending updates. They cannot tell you which CVEs you are exposed to, which are already closed by a backport, or which have no fix yet. That is what debsecan and dnf updateinfo add. See linux-scanning-and-detecting-vulns for the full treatment.

For fleet-wide visibility:

OpenSCAP: scan and report compliance with a security policy.
Anchore and Trivy: vulnerability scanners you can install and run yourself. Vulners is a commercial vulnerability database, not a distribution package; its scanner is a Python client that needs an API key.
Cloud-native: AWS Inspector, Azure Defender, GCP Security Command Center.

Common pitfalls

Unattended upgrades on production: critical services may break after an upgrade. Test in staging first.
Skipping security updates: missing security patches is the leading cause of successful attacks.
Manual upgrades on Friday: an unmonitored upgrade can cause an outage that nobody notices until Monday.
Forgetting reboots: kernel updates require a reboot. Track pending reboots with needs-restarting -r (RHEL) or /var/run/reboot-required (Debian).