When Microsoft released a patch recently for a major zero-day IE bug, it was noteworthy for how quickly the company turned it around. Eight days is really fast for Microsoft, probably a record, but would seven days have been better? That's not as easy a question as it may seem.

I'm sure that within a day or two Microsoft knew what code was being exploited and had a prototype patch out. A number of things can go wrong if you hurry up at this stage. First, and this is the main reason it takes Microsoft so long to come out with some patches, is the vast number of configurations that must be tested.

Consider this particular bug: every supported version of Windows, every supported version of Internet Explorer on them, every language. Then a whole lot of IE application code undoubtedly needed to be tested. I've done some test automation programming, and I'm sure Microsoft has put extensive resources into scaling up its test automation exactly for this situation: needing to test a large number of configurations as quickly as possible and to capture and analyze results from them. It's a task that can be highly parallelized, so if you design your test harness and tests well, you can throw hardware at the problem. I'm sure that's what happened here, and even so, I'm sure it takes awhile to test a patch thoroughly.

But there's more that needs to be considered. Often when a vulnerability, and subsequently a patch, comes out on some projects, it can come out quickly, but we find out soon afterward that the patch wasn't as comprehensive as it ought to have been. A Firefox/SeaMonkey patch from earlier this year introduced a stability problem that had to be fixed in a subsequent patch. And in what they claim was just an administrative error, the last big batch of Firefox updates mistakenly omitted one patch for Firefox 2. We've all heard of Microsoft patches that introduce instability; I can't find a well-documented example off-hand, but I'm sure there are plenty.

Another problem if you hurry up and patch is losing the forest for the trees: Are you patching a narrow issue when that issue is an aspect of a larger problem in the surrounding code? There are some programs, like the WMF code in Windows GDI, that have had multiple patches of the same basic type over the years. In the case of WMF, the format may be such that the parsing code simply can't be simple and there's no systemic solution. But it's certainly something to be careful about.

And then there are times when Microsoft seems to take far too much time to address a problem, as may be the case with the new SQL vulnerability just revealed a few days ago. The bug had been revealed to Microsoft, and the company acknowledged it, in April of this year, but it still hasn't done anything about it. This particular bug has all the earmarks of a simple one to fix; first, the problem only exists in some versions, generally newer ones, of their SQL products, so clearly it has been addressed in some way. My sense of this one is that Microsoft was waiting for some SQL Service Pack to put it in, but it took too long. Now events have overtaken the company, and it may be forced to separate out a patch, if only on the next Patch Tuesday, just because of the embarrassment of this.

Some companies routinely take a long time to issue updates to publicly disclosed vulnerabilities, Apple being the biggest offender. Is Apple making sure the patch is thoroughly cooked, or is it just not in a hurry? I suspect the latter is more of the case, and that Apple figures there is no hurry because Macs are still largely not on hacker radar.

Sometimes even with a dramatically important update it makes sense to wait. Consider the famous Kaminsky DNS bug updates of earlier this year, which were coordinated with all the significant DNS vendors. Almost all patched the same time (a few, like Apple, waited even longer) so that everyone would have the best chance to install the update before the attacks commenced.

There are many factors that feed into the prioritization formula for security updates. Microsoft has the hardest decisions not because its software is any less secure than anyone else's, but because it's so widely depended on and so widely attacked. It was obvious that the latest IE bug would be a severe one if left unpatched for very long, but perhaps not so for the SQL bug. And nothing, no matter how critical, ever seems urgent for Macs. Windows is the big city and the Mac is a small town, but even on Windows sometimes it makes sense for them to take their time.