What frustrates Ferderer and other security experts is the fact that this seemingly intractable problem is actually quite tractable. The tools and strategies to prevent another Slammer are just waiting to be used. In fact, the number of tools and strategies available to you?and available at a reasonable cost?makes it inexcusable for any CIO to fiddle while the software burns.

There is, after all, $60 billion on the table. A 2002 study by the National Institute of Standards and Technology (NIST) developed that number to describe buggy software’s cost to the national economy. Improved software testing alone, NIST suggests, could shave $22 billion off that.

Why can’t the software community motivate itself to grab all that cash? The answer lies in software culture.

Vendors, for the most part, value time-to-market over security. As long as they can get away with shipping buggy code, they will. (See "Sledgehammer," Page 64.)

Developers live by deadlines, which compel them to work fast. At the same time, they’re being asked to provide ever more features.

And CIOs, as a group, have been passive, assuming there was little they could do to effect change.

They assumed wrong. In fact, a growing number of advocates believe CIOs should be leading the charge for secure software.

"CIOs must take action," says Linda Northrop, director of the product-line systems program at the Software Engineering Institute (SEI) and coauthor of Software Product Lines: Practices and Patterns. "I think CIOs have done a deplorable job matching their software decisions to business goals, especially in its security and quality. What we need from the CIO ranks are leaders."

Northrop could be talking about Al Schmidt, vice president of IT and CIO of $939 million Arch Chemicals. "What I’ve come to realize," says Schmidt, "is that security is really about operational excellence. So why wouldn’t I jump on that? I mean, operational excellence?that’s what I’m supposed to be doing, right?"

Know Your Enemy

The vast majority of vulnerabilities in software arise from the following 10 basic development flaws.

1. Unvalidated parameters: Anyone can change a URL to access data. For example, switching "admin=no" to "admin=yes" within the URL gives the hacker admin privileges.

2. Broken access control: Software doesn’t check a user’s authorization properly, which means that credentials are cached and can be co-opted by anyone.

3. Broken account and session management: Hackers can take advantage of predictable validation schemes by, for example, manufacturing or altering cookies.

4. Cross-site scripting: User hits a poisoned webpage, which his browser accepts uncritically, allowing the hacker to access his machine.