Study Confirms the Government Produces the Buggiest Software 135
Sparrowvsrevolution writes in with a link to a Forbes story about the lackluster code produced by government agencies."Humans aren't very good at writing secure code. But they're worst at it when they're paid to do it for the U.S. government, according to a study that will be presented at the Black Hat Europe security conference in Amsterdam later this week. Chris Wysopal, chief technology officer of bug-hunting firm Veracode plans to give a talk breaking down a vulnerability analysis of 9,910 software applications over the second half of 2010 and 2011. Government-built applications came out far worse than those created by the commercial software industry or the finance industry. Only 16% of government web applications were secure by OWASP standards, compared with 24% of finance industry software and 28% of commercial software. By SANS standards, only 18% of government apps passed, compared with 28% of finance industry apps and 34% of commercial software. Wysopal and others blame the difference on a lack of accountability of federal contract developers, who aren't held to security standards and are even paid extra to fix their bugs after creating them."
That's because there's no profit motive. (Score:4, Insightful)
Gov't should be ideal for secure, bug-free develop (Score:5, Insightful)
There are industry-common metrics for good code.
With its focus on long-term outcomes, big budgets, and relatively stable personnel it seems to me non-outsourced government work would tend to produce better code.
Part of the government wrote the code for the space shuttle, the most bug-free program ever written. Seriously, look it up, that code is amazing.
The problem with these specific problems isn't with government but with improper requirements and possibly graft. These are much easier to fix on a local level than bad code in my not so humble opinion.
Contractors (Score:4, Insightful)
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. âoeThe 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. âoeIn 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.â
So what is everyone else's excuse? (Score:4, Insightful)
OK. So government contractor produce the shittiest code, due to a lack of accountability. However, the 34% rating for commercial software is absolutely horrible and inexcusable. Commercial software is almost twice as good, but twice as good shit is still shit.
Re:Hah! See? (Score:5, Insightful)
Private contactors, low-bidding, on the public's dime.
"We'll be here forever, boys. No need to get it right the first time."
Re:That's because there's no profit motive. (Score:3, Insightful)
On the contrary. Profit motive is exactly what caused this problem.
Contractors, motivated to get the greatest revenue for the least cost (time, effort, materials, whatever), created crap software. Since they don't suffer from producing crap software, they were simply working in their own (narrow view) best interest.
Perhaps if you were to hire employees that had motive to ensure the long term success of of a project (recognition, keeping your job) you'd get better results..
Re:Gov't should be ideal for secure, bug-free deve (Score:0, Insightful)
do you know what's lacking in the scenario you outlined, here, let me post again for those who weren't paying attention:
-long term outcomes = by the the time they're done, shit can the whole mess.
-big budgets = everyone is fat and happy, $800 wrenches, and $1500 toilet seats for everyone.
-relatively stable personnel = people's ass rooted to chairs. it's so fucking stable, you'll be hard pressed to find a pulse, much less a sense of urgency. ...it's not about finding the one thing that a government employee did well. One can always find a few examples of something done well.
But even in those cases, that are so rare, where the government did something well, it always falls on it's face when you factor in "how long did it take" (always wayyy too long), and "at what cost" (the costs are always ass raping with a drumstick. sideways.)
Re:Gov't should be ideal for secure, bug-free deve (Score:5, Insightful)
Actually, the Government had just about nothing to do with the Space Shuttle code.
The group that did it was founded by IBM and has been passed around to a number of other vendors (I believe they have ended up at LockMart).
I'm not sure if this supports or discourages your point.
myke
There's more reasons for this (Score:5, Insightful)
2. Much of government software is written last minute to meet the demands of the people we've elected that in turn force government agencies to create something from nothing, usually without proper funding and usually with unrealistic deadlines.
3. Much of government software is written by inexperienced people. Contractors and government employees are rehashed from project to project even as technology changes.
I've worked public and private for 15 years now in tech and have seen it all. DoD, Federal, and State projects from both sides of the contract/public servant side. A lot of government software is written in locations with smaller workforces leading to hiring people that are just the best you can get, now what you should get. The deadlines for government projects are almost always unrealistic. The powers that be, and I mean the legislature at the state level and agency heads in Federal, and the commanders/Washington in DoD work, don't feel like there's a ROI on almost any project, it's just stuff they "have" to do, so they don't take into account doing it right. They shoestring a budget, or don't even have a budget, and use whatever resources they can find to get things done.
Most projects aren't even contracted out completely. Many are sure. But I'd say more are a mixture of public workforce and contract or just done but the public servants at hand already. And yes, the contracted out ones are usually the worse IMO because the reason they got the contract is they "knew" the right person and it's a milking of taxpayer money. I've taken over for two projects completely outsourced to very large multi-national contracting firms whose names everyone would recognize. Both were over 70 million contracts. And both were complete crap. The systems were disgusting. We didn't even get printed binders for taking over the maintenance on either. We got some word docs in a network folder, the documents created "after" development was completed. A hodgepodge of technologies and some really bad code. For 70+ million you'd think you'd at least get a Tech Writer on the project and some bound color copies from Kinkos. Nope.
Re:That's because there's no profit motive. (Score:3, Insightful)
when both sides of the deal look after their interests, results tend to be a good bang for the buck spent. Government has no vested interest in getting a good deal and because of that it pretty much asks for being milked dry. On top of that the waste more often than not is rewarded with even more money in next year's budget.
Re:Hah! See? (Score:3, Insightful)
I think the problem is more that no decent programmer is going to be willing to work for the government. Working for the government or a highly-regulated industry means conforming to any number of pointless and horrible rules, created by people who have no idea what they're doing. It's soul-crushing, and no one would do it if they could possibly get a job elsewhere.
I recently helped a major bank update some of its internal software from 1980s QuickBASIC code (!) so it could run on Windows (!!)... it was badly-written stuff, with line numbers, sections of code that could never be reached, floating point equality comparisons that might not match, and other egregious flaws. In banking software that's been used for decades. Their email policy filtered out .BAS files, because the email administrator apparently confused .BAS files with VBscript, so I had to change the file extensions... until it turned out that their policy prohibited sending any source code "electronically", so I had to FAX print-outs for them to type in.
Of course their programmers were incompetent. Who would work in an environment like that?