Patching

What it means

Patching applies the fixes that vendors and maintainers release for the software you run: operating systems, databases, frameworks, libraries, container images and your own applications.

A security fix rarely arrives on its own. It comes inside a new version alongside other changes, so applying it means accepting those too. NIST frames the whole activity as preventive maintenance, which is a better description than emergency, and it makes patching a testing problem far more than a downloading problem.

Why it matters

Most successful attacks use flaws somebody had already fixed. Publication is the starting gun. The advisory explains the problem, working exploit code follows, and finding affected systems costs an attacker very little.

CISA keeps a catalogue of vulnerabilities known to be exploited in the wild, and it makes a far better queue than a list sorted by score. Patch levels are also the clearest signal of operational health an outsider can read, and old versions tell a customer, an auditor and an attacker the same thing.

How it shows up

What stalls patching is fear of breaking things, and the fear is usually earned. The answers are dull. Enough automated tests to tell you quickly whether an upgrade broke something, a staging environment that resembles production, and a cadence frequent enough to keep each upgrade small.

Watch the awkward cases. A framework two major versions behind, where the security fix exists only in the latest. A dependency held back by one incompatible package. A machine nobody owns any more. And base images in your container builds, which are either rebuilt on a schedule or never.