SEI and others such as @Stake are shining a light on these startlingfacts (and making money in doing so). It has started to have aneffect. Wysopal at @Stake says he's seeing more empowered andproactive customers, and in turn, vendors are desperately seeking waysto keep those empowered customers.

"It's been a big change," he says. "We still get a lot of [customerssaying], We're shipping in a week. Could you look at the app and makesure it's secure? But we're seeing more clients sooner in thedevelopment process. Security always was the thing that delayedshipment, but they've started to see the benefits - bettercommunication between developers, creating more robust applicationsthat have fewer failures. The truth is, it doesn't take that muchlonger to write a line of code that doesn't have a buffer overflowthan one that does. It's just building awareness into the process sothat, eventually, your developers simply don't write buffers withunbounded strings."

In fact, it's a little more complicated than that. Even if, startingtomorrow, no new programs contained buffer overflows (and, of course,it will take years of training and development to minimize bufferoverflows), there's billions of lines of legacy code out therecontaining 300 variations on the buffer-overflow theme. What's more,in a program with millions of lines of code, there are thousands ofinstances of buffer overflows. They are needles in a binary haystack.