Patching is part of what you take back
In a SaaS product, the security update is invisible: the vendor rolls it out across its own fleet, sometimes before the public announcement. The same vulnerability on an instance you host stays open until someone applies the fix. CVE-2026-63077 illustrates the gap: the flaw allowed unauthenticated execution of system commands on TeamCity On-Premises, fixed in versions 2025.11.7 and 2026.1.3, while the same vendor's cloud deployments required no action from customers. The gap is not technical, it is organisational.
What breaks when nobody owns it
- The installed version becomes untraceable — without an inventory, nobody knows which component runs on which machine, and a security advisory cannot even be triaged.
- The advisory reaches a dead address — vendor notifications go to a departed contractor's mailbox, or to an alias nobody reads any more.
- The backlog grows into a dead end — three major versions behind turns a ten-minute patch into a two-day migration.
- The update runs without a safety net — without a verified backup, a schema migration applied and then regretted cannot be replayed backwards.
- Nobody checks afterwards — the service restarts, the home page answers, and a queue consumer stays dead for weeks without a single signal.
The four prerequisites of a routine that holds
A patching routine does not rest on goodwill, it rests on four written things. An inventory: every application, its version, its host, its owner. Advisory sources narrowed to the components actually installed, because a general feed drowns the signal. An announced window: a recurring slot where downtime is accepted, otherwise the patch waits for a quiet moment that never comes. A restorable backup, tried before it is needed. Without those four, every update turns back into a project to negotiate.
The routine, in five moves
Inventory what is actually running
List every exposed application, its exact version, its host and its owner. docker compose ls then docker image inspect give the real state of your containers; dpkg -l or rpm -qa that of system packages. Keep this file under version control next to your configurations: an inventory that lives only in someone's memory does not exist.
Subscribe to advisories for installed components, not the whole internet
For each line of the inventory, open a named subscription: the repository's Atom release feed (https://github.com/org/repo/releases.atom), the vendor's security mailing list, or an NVD query filtered on the product. One subscription per component stays triageable. Route them all to a shared mailbox, never to a personal address.
Set a patch window, and a fast lane
Reserve a recurring slot where downtime is accepted and announced. Two classes are enough: ordinary patches wait for the window; a critical flaw under active exploitation triggers immediate application, outside the window. Writing that rule before the incident spares you from negotiating it during.
Back up right before, and prove the restore
Before applying, take a database export (mysqldump, pg_dump) and a dated backup of the data volume, then record the version you are leaving. A hypervisor snapshot and an application-level backup (restic, borg) do not cover the same risk: keep both, and test a restore while it is not urgent.
Verify behaviour afterwards, then hand it to a probe
An open port proves nothing. After each patch, check what the application really does: health endpoint response (curl -fsS https://your-domain.com/health), queues being consumed, a test email actually sent, no new errors in the logs. Then write those checks into permanent monitoring, with Uptime Kuma for instance, which replays them without you.
Shrink the surface instead of chasing patches
An admin console or an agent protocol exposed to the public internet turns every unauthenticated flaw into an immediate incident. Put those interfaces behind a private network, a VPN or an allowlist. Updating remains mandatory, but the delay between an advisory and your patch stops being a window of exposure open to everyone.
Who updates what, exactly
On a server you administer, the split must stay clear. The host provides and maintains the foundation: the machine, the network, the storage, hypervisor availability. The applications you install on top — their versions, their patches, their configuration — remain under your administration. Nobody will update them for you, and that is the price of the control you chose. The routine described here is what makes that split sustainable: it turns a diffuse load into a short, predictable appointment.
