Bug Scrubs and Learning From Mistakes
There’s a story at CNet, “Microsoft to hunt for new species of Windows bug:”
Microsoft plans to scour its code to look for flaws similar to a recent serious Windows bug and to update its development practices to prevent similar problems in future products.
Now, its’s easy to kick Microsoft for not having perfect code, but I think its far more interesting to look at how they’re handling this, and what we can learn from it. Security flaws are not acts of god, they’re mistakes in the code, and they follow patterns. Microsoft is putting effort into finding other instances of these patterns, and I suspect that a lot of that (unforutnately) is not automated. When these things happen, and they happen to most companies, people will audit your code and find other occurrences of the same bug. Ideally, those people will be working for you. Otherwise, you’re relying on the kindness of strangers for the security of your code.
(Disclosure: I’m doing lots of work for a startup that does code analysis things. Who knows, we might even have a website some day.) Also, Gunnar Peterson has a good post up on this topic at “Phasing Security into the SDLC – A Comparison of Approaches”
” We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better. Flaws have been found in just about every area of the system. Entire new classes of security problems have been found during our audit, and often source code which had been audited earlier needs re-auditing with these new flaws in mind. ”
The quote is from http://www.openbsd.org/security.html, where their code audit process is described. The emphasis is added.