Slashdot Mirror
Study Confirms the Government Produces the Buggiest Software
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."
And you thought it was Microsoft...
Duh.
I once took an excursion to Reddit, and later HN. Unlimited up/down voting sucks when dealing with a hive-mind.
Unfortunately, all the outsourcing going on in the Government (because it's easier to get money for a contract than to hire a developer on a permanent basis) is what's really killing the code here. Most outsourcing firms have a "throw the code over the wall" attitude, and spend more time deflecting blame for bugs than trying to fix them. I can't think of a business where there's less accountability than Government contracting, except possibly foreclosure management....
I work for a government agency and I can swear this to be the absolute truth. I believe the reason to be a lot of politicking in management and not enough actual IT experience. No one wants to step on toes or else it might come back to bite you later when you need funds for a project so when user X asks for feature Y in software Z and there is no way it can be implemented without hacking together a mess of SQL query strings that may or may not work, well then you do it, because if you don't do it. User X may at one point be on a committee that can divert funds from your server or software upgrade budget.
I got here through a series of tubes
I was a software tester for the DoD and can confirm the stupidity here. (I can't really talk about the exact program but I can tell you with 100% certainty that it was mission critical.) We were contracted to run massive amounts of automated testing on the latest build of the software I was working on. Upon finding bugs, we needed to do regression testing... to decide if we would fix them in the latest build, because if they were present in previous versions we were under no obligation to do so unless specifically paid to do so.
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.
If video games influenced behavior the Pac Man generation would be eating pills and running away from their problems.
Obvious loop hole...
"and are even paid extra to fix their bugs after creating them."
"If any question why we died, Tell them because our fathers lied."
The rules for government aquisition don't help. As there isn't any usefull formal metric for software quality, it normaly must settle with the cheapest competitor whoever it is, however it works.
Rethinking email
Reminds me of this Dilbert comic
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.â
Palm trees and 8
Spokesman of the German Home Office (BMI, in charge of the "Federal Trojan Horse" exposed by the CCC) at the Federal Press Conference 2011-10-12.
My first job was doing software for the federal government (mainly tools for tracking government property and assets and the nightmare of paperwork associated with them). It was _horrible_. It was a well paying job, great benefits, very relaxed (but political) environment .. but the atrocities committed to the art of software development combined with the painfully slow pace were unbearable.
Everything was always caught up in red tape. Requirements were always wrong, outdated, or both. In a lot of cases there was no clear time frame or end plan for software .. that shit would get figured out when/if the project was finished. And projects were often arbitrarily cancelled. Stuff that was finished and deployed often went unused for various reasons.
There was also an anti-change culture. Anything new was met with extreme resistance. Also there was this feeling that anything that improved our efficiency would decrease our staff. It wasn't entirely unfounded. Stuff was scheduled to take a certain amount of time. If it took less time, it wasn't like there was more work to fill in the holes.
And the code. Wow. I think it's part because the federal government has a lot of co-op/student programs .. and part because most programmers that care about software quality got the hell out of there (like I did) .. but the code that came out of my department was.. terrifying. Thankfully these were internal apps. Database queries involving multiple tables can be complicated.. but it's easy to put the same data in multiple tables! So just create multiple tables with the various data sets you need! Suggest a database view (at least half way to an ok solution) .. the DBA (yes, they had a DBA, a professional database guy, and he allowed this!) won't allow it (he won't reject it, he just offers to "look into it", which if you don't know is office politics for "nope!").
Ok I'm gonna stop and let my blood pressure come back down...
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.
In some other countries, government employees are smart and work hard. In South Korea for instance the gov't software all run on IE6 activeX plugins and are rock-solid.
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
Mimetics Inc. Twitter
1. Much of government is custom software. In the private world less so. Not that there aren't exceptions in either case, but my bank didn't write their own custom software for finances. In government it's almost always build over buy. It's much harder for the government to change policies to fit software when much of what they are writing software for is dictated by legislation.
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.
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.
That's it! Get rid of those nasty high level languages and get back to the bare metal with assembly. None of this new fangled junky stuff.
Kids these days. Never learn anything from their betters.
Faster! Faster! Faster would be better!
Government web applications are generally intended to Provide public information. 16% secure
Finance industry web applications are intended to transmit money the fact. 24% secure. The fact that this is less than twice as secure as web application that are generally informational only is frightening as heck.
Commercial applications are a mix of the two and come out to 28%. Strange.
Of course now the government is switching to agile/scrum (as opposed to the prior methodology of OMFGRAD) en masse so that requirements are gathered on the fly/after the fact and collected on sticky notes and discussed for 10 minutes a day. Because hell, if you can't get good requirements might as well have a methodology that minimizes the need for them.
Of course, considering almost all government software is dictated by business logic and legislation and often rely on existing legacy systems that can't be easily changed, I don't think it's exactly wise. I gag every time the cafe-latte sipping PM's gush about switching over toe scrum on another project so I can spend twice as long building software because my requirements are even worse now. But hey, it has a catchy name, it must be good for government work. We're all so grown up now.
It's not like a can get a high level requirement that I need to capture user information and go build a user screen in the government world. Every freaking little detail is going to be exacted upon on a user screen with rules and laws (and legacy systems) dictating what I can and can't do what is and isn't there and how it interacts with other systems. It's not that agile/scrum is always bad. It's just a square peg in a round hole of current government in most cases.
At least not 100%. You can blame the many headed beast they have to answer to. With every dept. head feeling they have to justify their existence by exerting power in the form of conflicting demands. Also add to this rule sets for compliance that are decentralized and NOT overseen by people who know how to program (generally) but instead know how to be gov't administrators. So compliance will often mean having internal conflicts as to what an application can do.
This is really about government controls run a muck.
In a way yes. A typical government project comes about by putting a team together for that project. It may be outsourced to a vendor, vendors bought in as staff aug, or done in house with existing IT resources. Or bought but that doesn't happen that often.
Now, since they're doing it as cheap as possible, maintenance is almost never factored in except on the biggest projects. The rest they just expect you to suck up with existing resources. And it's a one-off app so maintenance is as needed. Basically, once it's released (or the final release is put out considering a lot is done in iterrations) it's a dead system except when a bug is found. That accounts for the way a lot, but not all, government software is done. Which means, as opposed to a commercial package where a bug found by one customer and fixed by a support team can fix a bug for a 1000 customers, you're in your own fiefdom. Of course that hurts things. When you go to agency to agency, even within a single state or county, everything is done differently, looks differently, named differently. There are no true standards.
That said, almost every big consolidation effort in IT I've seen has failed miserably. Because by law/degree/legislation every single entity of government is so different and has such different rules to follow. Government is BIG. You're talking hundreds of thousands projects and developers and standardizing that is hard. It's a lot easier for Coke-a-Cola to standardize IT then it for all the soft drink makers to standardize IT practices. And government is like the latter x1000. And again, Coke-a-Cola's only going to do something that makes sense from a business standpoint and has a tangible ROI so they do it right to get that ROI (just an example, Coke IT might suck for all I know). Where as the government stuff almost never has an ROI, it's done because it's required to be done and isn't budgeted to be done, just required. With no ROI it's always just a "get it done" attitude. And a lot of stuff is done to make a politician happy so even though he has no idea what really should be done he has final say because he's going to use it to get favors with other politicians or to make a press release and use it for future votes.
There are a couple of assumptions here which are actually validated. One is that all government code is outsourced, actually its not.
The fundamental problem here is that government agencies especially can't tell shit from suger in terms of the quality of their software.
Industry can't tell them either, I know from experience that Government already spends enormous sums of money on processes which are meant to make software better, guess what? It doesn't work.
Government agencies (and staff promotions) are measured by inputs rather than outputs, ie how much they spend rather than what they produce, until this changes government software will be shit.
It's likely that the percentage of outsourced projects tracks the prevalence of security problems. Certainly, the government has a very high level of outsourced vs in-house development. I think that financial institutions also tend to largely outsource (especially customer-facing) development.
This isn't a study.
This is a press release declaring that everyone who is not already their client has a desperate need for Veracode's services. No different than when Norton sends out a "study" that shows how terribly dangerous the internet is or how much malware exists for smartphones.
This just sounds like they're angling to get themselves some more government business. And you know, kudos for them.
It breaks my pluginses, my precious!
Goverment are faget asshole too busy sucking gay faget cock to write good codes. We need to get rid of goverment and set up constitutional anarchy and send all the fagets away to France or some other faget country.
You'd be surprised how much software from all business models is written by queer folk! Microsoft actually lobbies the state of Washington for gender-neutral marriage so that they can poach more gay programmers. Google does the same. Your OS, browser and phone were probably designed by fagets. The field of computer science was founded by Alan Turing, an internationally infamous faget. Face it dude, queers are too smart and useful, you'll never get rid of us.
Governments are prone to several problems that cause serious problems with program quality. Speaking as a government programmer, starting with the biggest problem:
1. Consultants. Anytime you have someone external come in and build the code, they don't know anything about the business. They build whatever the spec is (hopefully). In my experience in government, specs are usually very bad at explaining what the users actually need. You need to understand the business in question pretty well to do that. Someone who actually understands how Environmental Inspection & Enforcement is done will be able to write a better program to do it then some guy who is just reading what a word doc says to build, because the first person has the knowledge to know when the spec is wrong.
And that's on a good day. Then you get the consultants who use crappy obsolete technology to throw stuff out quickly, hoping to get more money to fix it later. It won't integrate with anything else, because other consultants did that. When it needs changes because of legislative changes to the business put in by the politicians, nobody is going to know how to change it. It's an expensive and ineffecient model.
Whenever you hear about a $300 million system that didn't work, the odds are good a lot of consultants were involved.
2. Scope creep. Governments are infamous for this. They say we're going to do X. Then another branch jumps in later, now we're doing Y. Then another one. Oh, then there is a department merger and we need it to also work for some other department. Then there's an election and the priorities all changed. Good luck keeping up with that. It's made even worse if you're trying to do the project as one giant release that's all things to all people.
What governments need to do in order to deal with this inevitable problem is split projects up into phases and deliver smaller pieces. It's a lot better to get the first piece out there and in use in a relatively short timeframe then it is to try and build the entire mega-solution at once.
3. It's easy for government employees to become insular, because government is different from the rest of the industry. It's a trap to fall into where you don't keep up with what's new and changing just because you don't particularly need to. Given enough time, skills can become lax and obsolete. It's something that can be dealt with, but employees have to be encouraged to keep learning.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
where the p[people don't realize the 'government' isn't one group, one set of funds, or one set of guideline.
Oh wait? they sell a product? and don't release the details of said study? Maybe they do understand why a general grab at the generic label 'Government' makes for a misleading results.
The Kruger Dunning explains most post on
Many, not most. And for a great many of them it makes sense. Note: cost plus does not equal zero oversight. Just so you know.
Lets take a 5 year project on a piece of highway.
Seems pretty straight forward right?
Did you know the price of rock could double in that time period? or be cut ijn half? rock turns out to be more volatile then one would expect.
And that's just one component. IO unusually bad year can delay, fuel prices changes and so on.
Now, I know the media doesn't report this side of it, but sometime cost-plus has ended cheaper then estimated.
Eliminating cost plus will make thing more expense, and the results won't be any different.
Remember, we are talking about huge projects here. Many years. If you want a straight price bid, it means every bid would be 50% more then they are now, AND there would be more incentive for the contractor to screw you.
The Kruger Dunning explains most post on
and are even paid extra to fix their bugs after creating them.
this is the standard procedure when you, the client, approve work without kicking the tires. obviously there are some exceptional situations, and some legalese is required. if you don't want to pay for bugs to get fixed, either don't approve them or get a warranty. nobody writes bug-free code, that's a myth inherent in non-programmers. but on the whole, if you buy something without warranty, you get what you get. that's the whole point of charging extra for warranties.
if i'm a landscaper and i plant the trees you want me to plant, and later you find out they give you allergies, i'm not pulling the trees out for free. nor will i take shit off you for not knowing you're allergic. there are other analogies you could use to try to disprove me. my analogy doesn't prove me correct, but i believe i am and it helps illustrate why.
insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
Concludes, not confirms. Studies do not confirm anything (unless done by Netcraft).
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
I know that Slashdot has just copied the article title, but it seems incorrect:
- The article only seems to discuss security: this is only one class of bug.
- Surely a bug is a mismatch between the requirements and the implementation. If certain security criteria are not required, then it is not a bug if they are not met !
I suggest the title should be more like "Study Confirms The Government Produces The Least Secure Software".