When the first major wave of Internet attacks hit in early 2000, security software was the saviour, brought in at any expense to mitigate the problem. But attacks kept coming, and more recently, security software has lost much of its original appeal. That - combined with a bad US economy, a new focus on security, pending regulation that focuses on securing information and sheer fatigue from the constant barrage of attacks - spurred CIOs and CSOs to think differently about how to fix the security problem.

In addition, a bevy of new research was published that proves there is an ROI for vendors and users in building more secure code. Plus, a new class of software tools was developed to automatically ferret out the most gratuitous software flaws.

Put it all together, and you get - ta da! - change. And not just change, but profound change. In technology, change usually means more features, more innovation, more services and more enhancements. In any event, it's the vendor defining the change. This time, the buyers are foisting on vendors a better kind of change. They're forcing vendors to go back and fix the software that was built poorly in the first place. The suddenly efficacious corporate software consumer is holding vendors accountable. He is creating contractual liability and pushing legislation. He is threatening to take his budget elsewhere if the code doesn't tighten up. And it's not just empty rhetoric.

Mary Ann Davidson, CSO at Oracle, claims that now "no one is asking for features; they want information assurance. They're asking us how we secure our code." Adds Scott Charney, chief security strategist at Microsoft, "Suddenly, executives are saying: We're no longer just generically concerned about security."

So What Are We Doing About It

Specifically, all this concern has led to the empowerment of everyone who uses software, and now they're pushing for some real application security. Here are the reasons why.

Vendors have no excuse for not fixing their software because it's not technically difficult to do. For anyone who bothers to look, the numbers are overwhelming: 90 per cent of hackers tend to target known flaws in software. And 95 per cent of those attacks, according to SEI's Cross, among other experts, exploit one of only seven types of flaws (see "Common Vulnerabilities", right). So if you can take care of the most common types of flaws in a piece of software, you can stop the lion's share of those attacks. In fact, if you eliminate the most common security hole of all - the dreaded buffer overflow - Cross says you'll scotch nearly 60 per cent of the problem right there.

"It frustrates me," says Cross. "It was kind of chilling when we realised half-a-dozen vulnerabilities were causing most of the problems. And it's not complex stuff either. You can teach any freshman compsci student to do it. If the public understood that, there would be an outcry."

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

"It's been a big change," he says. "We still get a lot of [customers saying]: Â'We're shipping in a week. Could you look at the app and make sure it's secure?' But we're seeing more clients sooner in the development process. Security always was the thing that delayed shipment, but they've started to see the benefits - better communication between developers, creating more robust applications that have fewer failures. The truth is, it doesn't take that much longer to write a line of code that doesn't have a buffer overflow than one that does. It's just building awareness into the process so that, eventually, your developers simply don't write buffers with unbounded strings."

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