Bug-free software? Dream on

For software developers, writing quality code is only the beginning of an effective vulnerability-mitigation strategy

1 2 Page 2
Page 2 of 2

Open source developers like to tout "Linus' law," which says that "given enough eyeballs, all bugs are shallow." In other words, the transparency of the open source software development process means bugs in open source software will be caught and resolved more quickly than those in proprietary software.

But Microsoft security program manager Shawn Hernan disputes that claim, and credibly. According to Hernan, just because programmers can review code for bugs doesn't mean they actually do; furthermore, the evidence suggests only full-time, paid programmers are motivated enough to spend time reviewing someone else's code. If that's true -- and I think it's likely -- then only the software vendors with the deepest pockets (and thus the largest staffs) will truly be able to benefit from Linus' law.

Keep the channels open

But none of this should be taken to imply that software security is a lost cause. It isn't, but the key lies in recognizing that only so much can be done with code. It is the responsibility of any developer to ship code of the highest possible quality -- "highest possible" being the operative phrase. After that, the heart of any software developer's security strategy lies not in its development process, but in its process of dealing with security incidents when they inevitably arise.

The days of shipping software patches on CDs and floppy disks are long gone. Today, customers expect prompt delivery of patches almost as soon as vulnerabilities are discovered. While this may often be impractical, vendors delay delivery of critical patches at their peril.

Mind you, how vendors deliver patches can occasionally be problematic as well. Once, Microsoft delivered patches as soon as they were available, throughout the month. But customers complained that this made it too difficult to evaluate patches before deployment, placing an undue burden on IT staffers. In response, Microsoft switched to its current model of shipping fixes on "Patch Tuesday," twice a month. This method too has been criticized, particularly by those who claim that every Patch Tuesday leads to an "Exploit Wednesday," when hackers race to attack those who haven't applied the latest patches.

Customers will always gripe about security flaws and the need to patch them. The key is for developers to be as open and candid as possible about security issues related to their software, and to be forthright in offering assistance and advice to customers who may be affected, even before a patch is available.

The alternative is to foster a culture of silence and secrecy around security issues, and that's a recipe for failure. Toyota's situation is somewhat atypical. But closer to home, Web developers are champing at the bit for HTML 5, which they hope will free them from the seemingly endless series of bugs that have cropped up in plug-ins such as Adobe Reader and Flash, and that often go unresolved for weeks or longer.

As more studies like those from Veracode and WhiteHat Security come to light, customers are beginning to understand that security flaws in software are a fact of life. As that perception takes root, customers will increasingly demand not just patches, but greater disclosure of software security issues as they arise. Soon, software companies that don't regularly disclose security bugs won't be seen as the vendors with the highest-quality apps; they'll just be the ones with something to hide.

This article, "Bug-free software? Dream on," was originally published at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest developments in software development at InfoWorld.com.

Copyright © 2010 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a low-code development platform