Chapter 44. Improving Patch Management

Software has security flaws, as we well know, and we’ve seen a lot about why it can take time to get software fixed. But most of the time, fixes come out when a vulnerability is announced, and then the bad guys have a field day. Usually, they have at least a month in which they will have little problem finding people who haven’t patched.

But why can’t we get everybody to patch in a timely manner? After all, don’t most programs these days include auto-updaters so we don’t have to remember to go check for new software?

There are a couple of problems. In corporate environments, people like to make sure that patches are stable before allowing them to be deployed so as not to impact productivity. A security flaw that isn’t being actively exploited, or one that presents a low risk (perhaps because users are mainly behind the firewall, or perhaps users are just expected not to open random documents from around the Net) may not be as risky as installing an unstable patch that causes the program to crash a lot, thereby destroying productivity across an enterprise.

The patching problem isn’t just an enterprise problem. Normal people don’t patch, either. I see my parents and friends go for months or even years ignoring their computers’ cries for updates.

Heck, I don’t patch often enough myself. I don’t let things sit for years, but maybe a week or two.

The reason? Even if it’s mostly automatic, patching is usually a big productivity hit. If I patch my web ...

Get The Myths of Security now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.