Security continued.

James writes:

I also think that Microsoft should do extensive testing of the patches to see what they will affect, and even though this will not find all the problems that could be caused by the patch it could eliminate some of the issues created by patches. I think sometimes the patches are created as quickly as possible to fill a security hole, when it might better serve the entire community to take that extra week and do the testing and be sure that it will not break other things.

I'm sure Microsoft does a good amount of testing before they release, but you have to keep in mind that not everyone has the same environment. Even subtle differences between where it's tested and where it's deployed can make a big difference - and it's unrealistic to expect even a company of Microsoft's size to be able to test all possible scenarios.

As James pointed out and I conceded in my original post, even the most secure applications are inevitably going to need patching - that's just the way things are. The more secure the product when shipped, the less frequent critical patches will be released. The less patches you need to install, the more feasible it is that you can spend the time to thoroughly test in your environment, and the more likely that you will install a patch when it comes out.

A high frequency of patches can also trigger a "boy who cried wolf" syndrome of sorts. If there's only a handful of patches coming out, you may give more attention to them than being bombarded by critical updates every other week.

James also says that "the security battle is a hard one and has to be fought on many different fronts". I couldn't agree more.

Engineering