"Customers are vetting us," says Oracle's Davidson. "Not just kicking the tyres, but they're asking how we handle vulnerabilities. Where is our code stored? Do we do regression testing? What are our secure coding standards? It's impressive, but it's also just plain necessary.

"They have to be demanding. If customers don't make security a basic criteria, they lose their right to complain in a lot of ways when things go bad," she says.

At the bank, the security officer says, is a running list of vendors that are "certified" - that is, they've successfully met the application security criteria by going through the formal process. The list is an incentive for vendors to clean up their code, because if they're certified, they have an advantage over those that aren't the next time they want to sell software. Vendors, he says, "have either gone broke trying to satisfy our criteria, or they run through the operation pretty well. A few see what we demand and just run away. But there doesn't seem to be any middle ground."

In the US, the government is taking an active role. The image of the government in security is that of a clumsy organisation tripping over its own red tape. But right now, at least in terms of application security, the US government is a driving force, and its efforts to improve software are making a joke of the private sector.

In fact, no industry has been more effective in the past year at pushing vendors into security or using its clout (often, that comes in the form of regulation) to effect change.

At the state level, legislatures have collectively ignored the Uniform Computer Information Transactions Act (UCITA), a complex law that would in part reduce liability for software vendors (most major vendors have backed UCITA).

Federally, money has poured into the complex skein of agencies dealing with critical infrastructure protection, which has taken on a life of its own since September 11. Equally important but not as well publicised, the feds fully implemented in July the National Security Telecommunications Information Systems Security Policy No. 11, called NSTISSP (pronounced nissTISSip), after a two-year phase-in. The policy dictates that all software that's in some way used in a national security setting must pass independent security audits before the government will purchase it.

The US government has for more than a decade tried to implement such a policy, but it has been put off. Vendors have routinely been able to receive waivers through loopholes in order to avoid the process. The July move is considered a line in the sand. With national security on everyone's mind, experts believe waivers will be harder to come by. The US Navy is telling kvetching vendors to use NSTISSP No. 11 as a way to gain a competitive advantage. At any rate, products will have to be secured, or the government won't buy them. Like GE's contract, this makes software better for everyone.

The ability of the public sector to whip vendors into shape on application security is best represented, though, by John Gilligan, CIO of the US Air Force, who in March told Microsoft to make better products or he'll take his $US6 billion budget elsewhere. It was a challenge by proxy to all software vendors. At the time, Gilligan said he was "approaching the point where we're spending more money to find patches and fix vulnerabilities than we paid for the software". And he wasn't shy about labelling software security a "national security issue".

Microsoft chief security strategist Charney called himself a "nudge and a pest by nature", and he may have found his counterpart in Gilligan, who in addition to mobilising the Air Force is encouraging other federal agencies to use similar tactics. Gilligan says he was encouraged by Bill Gates' notorious "Trustworthy Computing" memo - his mea culpa proclamation in January that Microsoft software must get more secure - but that "the key will be, what's the follow-through?"