DEV Community

Hive80-lab
Hive80-lab

Posted on

We didn't patch for 14 months. Then the VPN bug chose our patch window for us.

For fourteen months, "we'll patch it in the next window" was the most successful sentence in our company. It survived three re-orgs, two deadlines, and one audit. Then a Tuesday morning arrived with a VPN advisory in it — remote code execution, auth bypass, exploited in the wild, our exact version — and the patch that had been waiting politely for 200 days started a week of chaos nobody had budgeted for.

The postmortem took one afternoon and produced one sentence that has run our operations ever since: if you don't choose your patch window, a CVE will choose it for you — and it will choose the worst possible one.

The cadence that replaced the fear

We didn't need a scanning appliance. We needed a short monthly loop, a triage rule, and the honesty to accept 4 minutes of downtime. Ours has eight steps; these are the four that did the heavy lifting:

  1. Triage advisories into 4 tiers. Tier 1: actively exploited or auth bypass — 48 hours. Tier 2: network-facing or RCE — 7 days. Tier 3: privilege escalation or local — 30 days. Tier 4: everything else — next monthly window. Before tiers, every advisory was urgent and nothing got patched. Triage is what turns 200 open CVEs into a queue you can actually finish.

  2. Snapshot before patch, rollback command written next to it. A patch you can't undo is a change — and it belongs in the same discipline as every other production change. We write the downgrade/uninstall command before running the upgrade. That one habit killed half our patch anxiety: the scary part was never the patch, it was the no-way-back.

  3. One production host before the fleet. No staging environment? Fine. Patch one host, run it 24 hours, then roll the rest in the window. "apt said ok" is not verification — check the version and the service health check with your own commands.

  4. Schedule the reboots. This was our dirty secret: hosts showed patched but ran yesterday's kernel for weeks, because nobody would sign off on the 4 minutes of downtime. A patched-but-not-rebooted machine is a server running the vulnerability with a green dashboard. Now reboots are part of the window, batched, with a watcher.

The rest of the loop is one inventory list, a 20-minute weekly advisory review, and a one-line log per host: date, CVEs, outcome, rollback used (yes/no). That log, boring as it looks, is the artifact that answers the auditor's question "how do you handle patching?" without anyone improvising.

The rules that survived contact

  • Reachable beats loud. A CVSS 9.8 on an internal box one admin can reach is usually less urgent than a 7.5 on your internet-facing gateway. Patch exposure order, not headline order.
  • Emergency patches get a retro-record, not a skip. When a Tier 1 lands mid-week, patch immediately — and write the log line within 24 hours. The rule isn't "no patches outside the window"; it's "no patches without a record."
  • End-of-life software is a project, not a patch. You cannot patch your way out of EOL. Anything past vendor support goes on the replacement list with a date. "We know it's risky" is not a control; it's an apology you haven't written yet.

The free version

The full checklist — the eight steps, the 4-tier triage table, the one-line patch log format — is on our ops notes site, next to the change-management and deployment-rollback guides it plugs into.

If you'd rather not assemble it yourself: the Ops Starter Kit Vol. 2 ($27) includes the full maintenance pack — patch log, maintenance-window calendar, change records — plus the advanced incident response and comms templates. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout.

And for the longer game — the routine jobs (patch batching, log shipping, health checks) running without a human remembering them — the Automation Starter Pack ($19) covers the pick-first workflows we used to stop relying on memory as an ops tool.

Top comments (0)