Patch management

The process has five parts and fails at whichever one is missing. An asset inventory of what runs where, because you cannot patch what is not on a list. Intake of vendor advisories mapped against that inventory. A decision on urgency. Deployment through a tested path with a rollback. Verification that the fix is actually present on the hosts, which is a separate step from the deployment tool reporting success.

What gets updated is not just the operating system. It is also the applications, the antivirus, the firewalls and any other component that runs third party code, and the fix almost always arrives as a patch or as a new version published by the vendor itself.

Two schedules run in parallel. A routine cycle handles the monthly flow. An emergency path exists for the small number of flaws that will not wait, and its value is entirely in having been used before, because a path first exercised during an incident is a plan, not a capability.

The estate is never uniform. Workstations and mainstream servers patch well; what stays behind is everything else, and everything else is where we get in. Network appliances, hypervisors, out-of-band management controllers, storage, printers, building systems, virtual appliances shipped by a supplier, and the one application server that a vendor contract says must not be touched. Those are frequently the internet-facing components with the highest privilege.

Verification is the other consistent gap. A deployment console showing full compliance while a service was never restarted, a container image rebuilt without pulling the fixed base layer, or a library patched in the operating system while the application ships its own bundled copy are all states we find and demonstrate. Where a fix genuinely cannot be applied, the answer is a documented compensating control with an owner and a date, not a risk acceptance that renews itself silently for four years.

Prioritisation should follow exploitation signals rather than CVSS alone: the KEV catalogue is the shortest useful list in existence. And what sits on the other side of not doing it is not theoretical: an exploit against a flaw that is already published and still unpatched is the cheapest way in an attacker has.

We report missing patches as reachable or not reachable, because those are different jobs and mixing them is what produces a backlog nobody works through. Where we exploit one, the finding carries the evidence and the identity we obtained, not just the version number. The most useful figure we hand back is usually the age of the oldest missing fix on a reachable host, which tells a client more about their process than any count. This is part of how we prove which missing patches are actually reachable.