Humans aren't generally very good at writing secure code. But it seems they're even worse at it when they're an employee of a government bureaucracy or hired as unaccountable federal contractors.

In a talk at the Black Hat Europe security conference in Amsterdam later this week, security researcher and chief technology officer of bug-hunting firm Veracode Chris Wysopal plans to give a talk breaking down the company's analysis of 9,910 software applications over the second half of 2010 and 2011, automatically scanning them for errors that a hacker can be use to compromise a website or a user's PC. And one result of that analysis is that government software developers are allowing significantly more hackable security flaws to find their way into their code than their private industry counterparts.

According to Veracode's analysis across industry and government, fully eight out of ten apps failed to fully live up to the company's security criteria. But breaking down the results between U.S. government and private sector software, the government programs, 80% of which were built for federal agencies rather than state or local, came out worse. Measuring its collection of apps against the standards of the Open Web Application Security Project or OWASP, Veracode found that only 16% of government web applications were secure, compared with 24% of finance industry software and 28% of commercial software. And using criteria of the security-focused education group SANS to gauge offline applications, the study found that 18% of government apps passed, compared with 28% of finance industry apps and 34% of commercial software.

"The government acts like security is the problem of the commercial sector and they're going to regulate everyone," says Veracode's Wysopal. "But if you look at this, private industry is definitely ahead of government."

When Veracode dug into specific vulnerabilities of web applications, it found that 40% of government web apps were vulnerable to SQL injection--a trick that uses hidden commands to hijack a database and was used repeatedly by the hacker groups Anonymous and LulzSec in their rampage through government and federal contractor systems last year--compared with 29% of web applications written by the finance industry and 30% written by the commercial software industry. For cross-site scripting, which allows an attacker to inject his or her own code into a website, 75% of government-written applications were vulnerable, compared with 67% in the finance industry and 55% of commercial software.

That institutional insecurity, says Alan Paller, researcher director of the SANS Institute, is the result of a private contractor system that actually rewards insecure coding. "The consequences for private sector software writers who write insecure code in commercial software is high costs for patching along with substantial embarrassment for their companies and job insecurity for them," he says. "In contrast, the consequences for private sector software writers who write insecure code for the government is contract add-ons to fix the problem, and more revenue for their companies and job security for them."

"You’d think they’d be really worried about someone asking a fix to a security problem. But those are just called change orders. And that’s how a project manager makes his bonus," Paller adds. "I'm not claiming that contractors aren't trying to do the right thing. But this is how the incentives are built."

Those incentives have led to government bugs persisting even as the rest of the industry starts to clean up its act, says Veracode's Wysopal. While SQL injection and cross-site scripting vulnerabilities have have dropped off in private industry over the last two years, they've remained statistically flat for governments.

The problem boils down to an oversight in the regulations for government software set by the National Institute of Standards and Technology, says Wysopal. NIST's rules outline security standards for network security--systems like firewalls and intrusion detection systems--as well as endpoint security like antivirus programs. But only the latest round of its regulations included standards for coding secure applications, and even those didn't extend to most of the government's web applications. "We're zeroing in on the application layer, but that's something that's been pretty much ignored in the government space," says Wysopal. "They don't take a risk-based approach. They take a compliance-based approach. If it's not in the regulations, it doesn't get done."