Patch Management: Fast Is Good, Instant Is Not

GitHub has started holding dependency updates for 72 hours before applying them. That looks backwards, since the entire point of automated updating is speed, and two days ago we were arguing that shrinking patch windows make slowness expensive. Both things are true, and the reason they fit together is worth understanding, because it tells you something useful about how to handle updates in an ordinary business.

Two risks pulling in opposite directions

Patching involves a genuine trade-off that rarely gets stated out loud.

Update slowly and you sit exposed to flaws that are publicly known, documented, and easy to exploit. That is the common failure and it is responsible for an enormous share of real incidents. Update the instant anything ships and you inherit a rarer but nastier problem: if an attacker has compromised a package, you install their code automatically, at machine speed, before anyone has noticed.

A short delay threads between them. Compromised packages tend to get spotted and pulled within a day or two, because a lot of people are watching. Waiting 72 hours means you dodge most of that while still being current by any reasonable standard.

Who this applies to

If nobody at your company writes software, you live in the top two rows. Keep automatic updates on and stop thinking about it. The nuance in the bottom row is a developer problem, and reading about it should not talk you into switching off the thing protecting you.

The four steps almost nobody does

Patch management sounds like an enterprise discipline with a budget attached. For a small business it is four things, and most of the value is in the first and last.

List what you run. Every piece of internet-facing software, including the things installed years ago by someone who has left. You cannot patch what nobody has written down, and this is where almost every real gap hides.

Turn automatic updates on. Everywhere they exist.

Set a rough target for the manual ones. Within a week for normal fixes, same day for anything flagged critical. Rough is fine. Having no target at all is what produces the three-versions-behind booking system.

Verify it is actually happening. This is the step everyone skips. Automatic updates fail silently all the time, because a disk filled up, a credential expired, or a machine has not been restarted since March. Check quarterly. Ten minutes.

Your suppliers are your patch schedule

For most Canadian small businesses, the majority of exposure sits in software somebody else hosts. Your booking system, your CRM, your online store. You cannot patch any of it, which makes their speed your exposure.

So ask. How quickly do you ship a fix once a serious flaw is confirmed, and how will you tell us when something affects our data? Two questions, and the quality of the answers separates suppliers fast. They sit naturally alongside the wider set in using the emerging AI security standard as a buyer checklist.

Why this is getting more urgent

Flaw discovery is speeding up considerably, which we covered when the strongest vulnerability-hunting AI became purchasable. More flaws found means more patches published, and a shorter gap between publication and exploitation. Being slow costs more than it did a year ago.

At the same time, the supply chain itself is a target, and AI tooling has expanded it. Staff install extensions, plugins, and add-ons that pull code from places nobody vetted, which is the pattern behind malicious AI skills spreading through a marketplace. Both pressures point at the same boring answer. Know what you run. Keep it current. Make someone responsible for noticing when updating quietly stops.

Frequently Asked Questions