Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Study Confirms the Government Produces the Buggiest Software

samzenpus posted more than 2 years ago | from the too-many-cooks dept.

Government 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."

cancel ×

135 comments

Sorry! There are no comments related to the filter you selected.

Hah! See? (2)

No, I am Spratacus! (2281684) | more than 2 years ago | (#39354991)

And you thought it was Microsoft...

Re:Hah! See? (5, Insightful)

Jeremiah Cornelius (137) | more than 2 years ago | (#39355285)

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:Hah! See? (1)

Anonymous Coward | more than 2 years ago | (#39355337)

Bidding?!

There ain't no business like no-bidness.

-- Ethanol-fueled

Re:Hah! See? (-1)

Anonymous Coward | more than 2 years ago | (#39355385)

It's no joke.

A lot of government stuff is "make-work" jobs. For most of those contracts, quality is the least of the concerns. Many times the shoddiness is on purpose. It keeps them busy. Just like how the same roads have to be repaved almost every friggin' year. If the government contractors did it right, they'd be out of work the next year.

Re:Hah! See? (1)

Jeremiah Cornelius (137) | more than 2 years ago | (#39355579)

It's like this in private-sector, too. Just so, in Government the objective is not profitablility - so th eoversight tends to be more severely lacking.

I watched a crappy little 2 man dev shop bilk a retirement planning group in a major finacial services corporation. They wrote crappy dBase code, with crappy multi-user kludges that all required lifecycle maintainance, patches, rewrites and updates. They could never port off of dBase/NetWare, and I finally helped evict them with the coming of IP networking.

Re:Hah! See? (-1)

Anonymous Coward | more than 2 years ago | (#39355715)

Just like how the same roads have to be repaved almost every friggin' year.

I don't know about where you live, but around Minneapolis/St. Paul they need to be repaved because of *winter*, not shoddy construction.

Re:Hah! See? (1)

Pope (17780) | more than 2 years ago | (#39356165)

"It isn't government work if you don't do it twice!" Jerry Gergich

Re:Hah! See? (1)

Anonymous Coward | more than 2 years ago | (#39356185)

Uhh.. did you even read the summary? The private sector was only had an additional 8% that was secure. That's so low of a difference it may even be within the margin of error.

LOL @ #buttes, failures. (-1)

Anonymous Coward | more than 2 years ago | (#39355023)


 

Goverment are faget (-1)

Anonymous Coward | more than 2 years ago | (#39355045)

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.

LOL (5, Funny)

nthwaver (1019400) | more than 2 years ago | (#39357121)

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.

That's because there's no profit motive. (4, Insightful)

MyFirstNameIsPaul (1552283) | more than 2 years ago | (#39355065)

Duh.

Re:That's because there's no profit motive. (3, Insightful)

Anonymous Coward | more than 2 years ago | (#39355303)

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:That's because there's no profit motive. (2)

MightyYar (622222) | more than 2 years ago | (#39355653)

So draft the contract such that the government (or some agent of the government... another bidder?) gets to report bugs and the service is not complete until the bugs are gone. Sure the bids will cost more, but it seems like an easy way to solve this particular problem.

Re:That's because there's no profit motive. (1)

Anonymous Coward | more than 2 years ago | (#39355803)

Few small challenges. 1st, you put that in the RFP, not just the proposal. Second, FAR's require a fixed period of performance for all contracts. Third, you sure as fuck don't want this on a service contract, or you'll get nothing but a level of effort from the contractor. Fifth, define "bugs". Sixth, do you really want to continue to pay $slimy_contractor to fix bugs that don't cause a real problem. Seventh, that still doesn't in any way give you any hope of actually getting a usable product. Your response is naive, foolish, and qualifies you to vote for the congressmen who have given us the fucked up acquisitions system.

Re:That's because there's no profit motive. (1)

MightyYar (622222) | more than 2 years ago | (#39356215)

You completely misunderstand. They would certainly not get paid to fix bugs, and in fact the full payout would be withheld until they were fixed.

Do we really need to define bugs in a Slashdot forum? I suspect it would take pages of legalese and probably involve an arbitration mechanism.

Re:That's because there's no profit motive. (1)

Rich0 (548339) | more than 2 years ago | (#39356439)

So draft the contract such that the government (or some agent of the government... another bidder?) gets to report bugs and the service is not complete until the bugs are gone.

Yeah, but would the guy writing the contract want to do that to the nice guy who takes 12 senators per month out to a really nice lunch, and makes sure they're always stocked with the latest gadgets/etc?

Re:That's because there's no profit motive. (2, Insightful)

Vaphell (1489021) | more than 2 years ago | (#39355679)

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:That's because there's no profit motive. (1)

rmstar (114746) | more than 2 years ago | (#39355857)

Government has no vested interest in getting a good deal and because of that it pretty much asks for being milked dry.

Why is that? Just because you say so? What is that "government" you are talking about?

Government officials have a natural tendency, like anybody else, of trying to do a job they can be proud of. There are many reasons why they don't manage (just look at the Jefferson County disaster [rollingstone.com] ). But lack of interest in good results by officials is currently not the most important one.

Re:That's because there's no profit motive. (2)

skids (119237) | more than 2 years ago | (#39355935)

Actually initial attitudes come into play here as well.

If there's a bagel shop that is owned by a guy who only catches 15% of shoplifters, and one which is owned by a guy who catches 25% of shoplifters, but the second guy has a reputation for getting his bagels lifted, shoplifters will go to the second guys shop preferentially, and he'll have more bagels shoplifted despite his vigilance.

As long as there is a general attitude that government == "cash cow" among the private contracting sector, whether or not the government gets better at holding contractors accountable, they will still be victimized more. If contractors suddenly changed their stripes and demonstrate some patriotism, the story would be entirely different.

Re:That's because there's no profit motive. (3, Interesting)

El Torico (732160) | more than 2 years ago | (#39356415)

The profit motive is part of it, but only a part. Usually, the customer has undefined or poorly defined requirements and grossly incompetent management. I was once part of a program in which the government representative refused to provide the security standards and criteria that the system would be judged upon. We had conflicting standards to reconcile and every request for guidance or additional information was ignored.
That was only part of the problem. The network design was provided by the government and it was a complete mess; we couldn't change it either.

Re:That's because there's no profit motive. (0)

Anonymous Coward | more than 2 years ago | (#39356671)

You get what you pay for. Usually the lowest bid wins the contract.

Contractors (5, Interesting)

Anonymous Coward | more than 2 years ago | (#39355083)

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....

Re:Contractors (5, Informative)

BenEnglishAtHome (449670) | more than 2 years ago | (#39355901)

I just retired from a long IT career with a fed TLA.

In all that time, there were two projects that stood out in my mind the most.

For the first one, a division needed software to automate their primary tasks. If such software could be implemented, it would essentially be where 20,000 people a day spent all their time and brought in billions of dollars. The solution they decided on was to survey the end users who were tired of doing everything on paper, find the ones who were the acknowledged computer geeks, then let them design and write the program. They actually turned field civil law enforcement officers into SAs and analysts and coders and let them build what they needed. It took years but when it was done, it was a thing of functional beauty. Actually, it was ugly as hell but it so perfectly met the needs of the field officers that I know of several who actually delayed their retirements so they could spend more time doing a job that was fun again because all the drudgery had been automated away.

Most. Successful. Project. Ever.

The other one I remember was the same sort of thing, a program that some 70,000 would spend all their time in. It was buggy from the start. The people who had to use it hated it. Every upgrade broke reports from the previous version. It was, obviously, done by contractors. At one point, development halted for almost 18 months because someone dropped a dime on the contract developer and their entire staff of Indian programmers with expired visas had to pack up and go back to Asia. The contractor folded up shop and getting another to step in, untangle the mess, and start moving forward was a royal pain.

My point?

Sometimes, coder skill is meaningless. If you have developers and architects and all those other job titles involved in software development who actually work for the government because, at least in part, they are proud to serve their country...then you get better software.

Government software should be created by government employees, not contractors.

Now I'll go back to my place in the 1950s, where I'm sure many of you will say I belong.

Re:Contractors (1)

Anonymous Coward | more than 2 years ago | (#39356051)

i think it's unfair to judge all contractors as such. i've seen government employees sit on their ass because it's damn near impossible to fire them and they can't be matrixed or anything, so they just coast the last few years til retirement. i've seen contractors work their ass off because they have to basically re-bid every year to keep their job and there is always competition from another contractor that wants that job. Contractors have to keep proving themselves. Government doesn't. The real problem are the few problem child contractors that have connections with someone higher up so they keep winning because they know people. they hire shoddy developers and just get by because it's too much work to throw them off due to their connections and no one wants to rock the boat.

Re:Contractors (2)

Liquidrage (640463) | more than 2 years ago | (#39356279)

100% no doubt. I've said time and time again I can fix a lot of state IT if I could do two things:
1. Fire people like it was the private sector
2. Pay competitive wages for new hires

What a lot of people don't realize about the gov, especially in IT, is if you take any 5 gov IT employees 2 are underpaid worthless cretins that should lose their job but the manager doesn't have 40 hours a week just to document their deficiencies because he/she is actually working. 2 are making what they're worth but are underskilled for the job and the pay reflects that, and one's a complete stud vastly underpaid and doing hero work to make sure things run. Obviously those numbers aren't exact science, but it's like that in a lot of places.

Re:Contractors (2)

f97tosc (578893) | more than 2 years ago | (#39356711)

I think in general it is very difficult to have two groups of separate people, one who understands the problems, and another who understands how to write code.

IN theory you let the users write down a list of specifications, but it rarely works into problems. You always run into trade-offs and conflicts involving functionality vs complexity for example, only somebody who understands both the software and the problem situation can resolve this well.

I agree with you that the best solution is to have the users learn how to code, or possibly let the coders learn how to run the business. Unfortunately I think it is rare to find the right combination of talent. And certainly users without coding talent are not going to declare themselves incompetent to manage in business with increasing software content. And coders are all too comfortable letting somebody else specify what to code and not taking ownership for a product that actually adds value.

Re:Contractors (2)

Tridus (79566) | more than 2 years ago | (#39357137)

You're absolutely right. I work as a programmer for the government and I see the same thing. The stuff that's built in house by any department (not just ours, but I think we do good work) tends to be better. We don't get paid extra to fix bugs - we just get unhappy users and lousy performance reviews for having lots of bugs. As part of the department we actually learn the business and can thus do a better job.

The stuff made by contractors is made to specification, if you're lucky. The problem is that the specification is usually wrong, because non-technical users don't have a clear grasp on what it is they actually need. The successful projects are very much iterative ones, because as soon as you give users something they'll be coming back with changes and new requests and other business areas will be impacted. It's inevitable.

The contractor model is great to make the friends of politicans a lot of money. It's a failure if you want good software.

Re:Contractors (0)

Anonymous Coward | more than 2 years ago | (#39357299)

Actually, in my experience (as a government IV&V entity) that's only half true.

The "throw the code over the wall" part is there. However, they're happy to admit the bugs are there. Because data rights to the code are often retained by the contractor, and they are HAPPY to try to fix the bugs, because they are kept on a T&M contract to repair any problems the government finds. Which just means more work and more pay for them.

I can attest to this (4, Interesting)

Reverand Dave (1959652) | more than 2 years ago | (#39355107)

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.

Re:I can attest to this (1)

Carewolf (581105) | more than 2 years ago | (#39355227)

So you can attest that government code quality is _SLIGHTLY_ more buggy than commercial code?? Notice the percentages, the wast majority of commercial code is complete crap too, the percentage is just _slightly_ higher for the government.

Your story is the same story everywhere. Nothing special for the government only more common.

Re:I can attest to this (1)

Baloroth (2370816) | more than 2 years ago | (#39355359)

So you can attest that government code quality is _SLIGHTLY_ more buggy than commercial code?? Notice the percentages, the wast majority of commercial code is complete crap too, the percentage is just _slightly_ higher for the government.

Financial web applications are 50% more likely than government one to be secure, and commercial software is almost double the government stuff. That isn't _slightly_ that is significantly. Yes, the vast majority of code everywhere sucks, the government just sucks considerably (not slightly) worse than regular business software.

Re:I can attest to this (0)

Anonymous Coward | more than 2 years ago | (#39356293)

I guess we disagree on this one. You can make up statistics all day, but in the end everyone gets 0wned. 72% ownable isn't really something you should be crowing about how the private sector is so much better.

Re:I can attest to this (1)

Carewolf (581105) | more than 2 years ago | (#39356695)

That is a valid perspective. I just considered anything below 90% secure (and this is not real security checks, just a check for really common mistakes) as so bad it doesn't really matter.

Re:I can attest to this (2)

scot4875 (542869) | more than 2 years ago | (#39356735)

Financial web applications are 50% more likely than government one to be secure

50% more than not very likely is still only slightly more likely.

--Jeremy

Re:I can attest to this (0)

Anonymous Coward | more than 2 years ago | (#39355363)

Been using punctuation long?

Re:I can attest to this (0)

Anonymous Coward | more than 2 years ago | (#39355761)

Except NASA [fastcompany.com] . Maybe the shuttle team needs to be repurposed to other areas needing development?

the shuttle software group is one of just four outfits in the world to win the coveted Level 5 ranking of the federal governments Software Engineering Institute (SEI)

Healthcare.exe, Waronterror.exe (1, Funny)

Anonymous Coward | more than 2 years ago | (#39355125)

This program has performed an illegal operation and must be shut down.

If the problem persists, contact the program vendor.

Yes. (5, Interesting)

Cantide (743407) | more than 2 years ago | (#39355137)

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.

Gov't should be ideal for secure, bug-free develop (4, Insightful)

Iamthecheese (1264298) | more than 2 years ago | (#39355139)

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.

Re:Gov't should be ideal for secure, bug-free deve (0, Insightful)

Anonymous Coward | more than 2 years ago | (#39355347)

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 (4, Insightful)

mykepredko (40154) | more than 2 years ago | (#39355409)

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

Re:Gov't should be ideal for secure, bug-free deve (3, Funny)

ColdWetDog (752185) | more than 2 years ago | (#39355507)

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 [wikipedia.org] . None of this new fangled junky stuff.

Kids these days. Never learn anything from their betters.

Re:Gov't should be ideal for secure, bug-free deve (1)

Tridus (79566) | more than 2 years ago | (#39357165)

Contractors don't care about that stuff. They're there to build something as quickly as possible that meets the minimum spec so they get paid. Bugs just mean future work.

Laugh (3, Funny)

koan (80826) | more than 2 years ago | (#39355163)

Obvious loop hole...
"and are even paid extra to fix their bugs after creating them."

Re:Laugh (2)

mcavic (2007672) | more than 2 years ago | (#39356161)

and are even paid extra to fix their bugs after creating them

There's no getting around that. Programmers have to eat too.

Re:Laugh (1)

ae1294 (1547521) | more than 2 years ago | (#39356787)

There's no getting around that. Programmers have to eat too.

PERL programmers don't...

Hiring the cheapest competitor doesn't help either (3, Informative)

marcosdumay (620877) | more than 2 years ago | (#39355183)

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.

Re:Hiring the cheapest competitor doesn't help eit (1)

mini me (132455) | more than 2 years ago | (#39355465)

I don't know about the US government, but I see things with my local government like: You need a degree in computer science to build a webpage. CS grads are generally not skilled in producing such works, so you end up either picking from the limited group of people who are, or more likely you choose someone who is not a good fit for the job and end up with poor results.

Re:Hiring the cheapest competitor doesn't help eit (1)

Anonymous Coward | more than 2 years ago | (#39355641)

There is a useful formal metric, maintenance cost. The lowest price including both development and maintenance for the entire anticipated lifespan of the product should be used, not just the development rate. Unfortunantly, that's too rational, odds are the not yet approved metric for software quality will be something like 'whatever uses more RAM.'

"even paid extra to fix their bugs after creating" (3, Funny)

SwashbucklingCowboy (727629) | more than 2 years ago | (#39355193)

Reminds me of this Dilbert comic [dilbert.com]

Contractors (3, Insightful)

betterunixthanunix (980855) | more than 2 years ago | (#39355201)

My first though was, "Probably the work of contractors." Then I RTFA'd and had it confirmed:

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.â

Re:Contractors (0)

Anonymous Coward | more than 2 years ago | (#39355313)

People, including programmers, do what they get paid to do. In this case, creating buggy software gets you paid more so what are you gonna do? You're gonna write buggy software.

Re:Contractors (1)

Bogtha (906264) | more than 2 years ago | (#39355969)

Yup. Government also produces the least buggy software. I believe NASA holds the record for fewest bugs per line of code.

Re:Contractors (0)

Anonymous Coward | more than 2 years ago | (#39357211)

At orbit high cost.

We lack the expertise 2 program a complete program (2)

D4C5CE (578304) | more than 2 years ago | (#39355207)

Die Expertise, ein gesamtes Programm zu programmieren, ist nicht vorhanden.

Spokesman of the German Home Office (BMI, in charge of the "Federal Trojan Horse" exposed by the CCC [h-online.com] ) at the Federal Press Conference 2011-10-12 [bundesregierung.de] .

Not susprised at all (3, Informative)

Anonymous Coward | more than 2 years ago | (#39355245)

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...

Yeah, well (1)

RPGillespie (2478442) | more than 2 years ago | (#39355251)

We're a heck of a lot better at writing secure code than the other animals

Re:Yeah, well (0)

Oswald McWeany (2428506) | more than 2 years ago | (#39355433)

I disagree. My cat has NEVER written unsecure code.

Re:Yeah, well (0)

ae1294 (1547521) | more than 2 years ago | (#39356881)

My cats code is also Perrrfect!

So what is everyone else's excuse? (3, Insightful)

rudy_wayne (414635) | more than 2 years ago | (#39355275)

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."

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.

Outsourcing, all around (2)

mbessey (304651) | more than 2 years ago | (#39356529)

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.

Thats only the US Gov't (3, Funny)

Spy Handler (822350) | more than 2 years ago | (#39355331)

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.

Blah (0)

Anonymous Coward | more than 2 years ago | (#39355333)

pretty good for government work.

Interpret however you like (1)

djdanlib (732853) | more than 2 years ago | (#39355357)

Wow, I just found out that I'm better at something than the government.

There's more reasons for this (5, Insightful)

Liquidrage (640463) | more than 2 years ago | (#39355423)

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.

Re:There's more reasons for this (0)

Anonymous Coward | more than 2 years ago | (#39356137)

Amen. Been there, done that. It's hard to imagine the incompetance and waste until you see if for yourself during a few projects. Not to mention the prima-donna attitudes that most big contractors have.

Re:There's more reasons for this (0)

Anonymous Coward | more than 2 years ago | (#39356365)

1. Legislated failure is still failure, and not doing something right because it's hard is not an acceptable reason for poor performance.

2. The last minute problem is definitely there.

3. There is definitely a lack of personal accountability, probably driven by the stringency of the background checks. The Gov doesn't have firing and lay offs like the private sector(non-contractor) does, which leads to marginally competent people working many of these failing projects. I sometimes joke that most DOD projects require a clearance and pulse, but in a pinch you can get a waiver for the pulse.

It's definitely true that the contractor incentives are not aligned well, but then again look at the people running these projects. Creative destruction is a necessity and in it's absence the Peter principle flourishes.

communism (1)

Lehk228 (705449) | more than 2 years ago | (#39355445)

Remember, if the government were to hire it's own developers to make government systems that would be communism and if those developers were allowed to unionize and put their foot down to halt a known bad release until it was correct and secure, that would be ultra-communism

One other factor (1)

Anonymous Coward | more than 2 years ago | (#39355553)

Other contributors have mentioned good reasons for government code being less secure. I'm going to give another interpretation: sample bias.

How do you get a representative sample of industry code or government code? It's just not possible.

Sounds like they have little practical experience (1)

MikeRT (947531) | more than 2 years ago | (#39355563)

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.

Ah yes, blame the contractors for everything. Ignore the fact that not that long ago, one of the highest ranking federal IT officers came out and basically confessed that most federal IT projects fail because most of the federal government doesn't even remotely handle requirements gathering properly. That's a nice way of saying they have a lot of money and don't know what they want to do with it, but damned if they're not going to blow it anyway before firmly figuring out what they need.

Re:Sounds like they have little practical experien (4, Interesting)

Liquidrage (640463) | more than 2 years ago | (#39355717)

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.

Different markets. (2)

MindStalker (22827) | more than 2 years ago | (#39355647)

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.

Stuxnet was pretty solid though (0)

Anonymous Coward | more than 2 years ago | (#39355737)

On a more serious note, I wonder if this is related to all the disparate contractors actually writing the programs?

Re:Stuxnet was pretty solid though (1)

hemo_jr (1122113) | more than 2 years ago | (#39355805)

I see this as proof, positive that Stuxnet was not a U.S. government product.

Re:Stuxnet was pretty solid though (2)

Liquidrage (640463) | more than 2 years ago | (#39356153)

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.

Don't blame the contractors... (3, Informative)

retech (1228598) | more than 2 years ago | (#39355989)

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.

Part of the problem is the "do it cheap" mindset (0)

Anonymous Coward | more than 2 years ago | (#39356099)

from management and the customers. Unit testing, regression testing, QA, code reviews, proper design, refactoring once problems are found. These are all discouraged because "the customer wants it now" or "it's not in the contract". Also as others have mentioned, the hiring of essentially coding mercenaries (contractors) that do not stay with the company long-term and have no accountability or interest in long-term quality. Plus, it's cheaper (on paper at least) to hire a contractor at an hourly wage than an actual full-time software engineer.

Cost + Fixed Fee (1)

englishknnigits (1568303) | more than 2 years ago | (#39356121)

This is partially due to the Cost + Fixed Fee model which encourages companies to reinvent the wheel instead of developing and using stable, tested code bases. Spending more money grows your revenue and your company, being efficient and spending less money limits the growth potential of your company. The second major reason is they are married to outdated development practices like the Waterfall model and generally answering new/potentially better ideas with "No, that's not the way its done."

Government certification (0)

Anonymous Coward | more than 2 years ago | (#39356179)

Why is it such a hurdle to get software certified for government use when the government can't even write merely competent software?

Cost-plus (1)

Todd Knarr (15451) | more than 2 years ago | (#39356181)

Well, duh. Thanks to the rules (lobbied for by we-all-know-who), most government contracts are cost-plus: the contractor's paid the bid plus any additional costs that come up after the bid. With those terms the best approach is to low-ball the bid to insure you win it, do a shoddy job and then bill any time needed to fix the problems as an additional cost.

The fix is obvious: eliminate cost-plus. Make the standard terms fixed-cost: the contractor's paid the amount bid to deliver the goods as specified in the bid, and if they don't meet spec the contractor has to eat any costs needed to correct the deficiency. The only costs that're paid beyond the bid are those for changes the government requested after the bid was placed, and those costs are fixed before the changes are started. But the lobbyists for the big government contractors will fight that tooth and nail.

Re:Cost-plus (0)

Anonymous Coward | more than 2 years ago | (#39357043)

In 12 years of working in software development I can say without a doubt no one is ever happy with fixed cost projects. The customer feels they didn't get what they paid for and the developer feels they got killed with scope creep. What would be better is the ability to allow the people in charge of these projects to do business with companies that produce quality work and to choose not to do business with companies that produce crap. Obviously add in some oversight wrt kickbacks and favoritism. As it stands if you're the lowest bidder the government is legally obligated to use you, even if you've proven to be horrible to work with in the past.

Re:Cost-plus (2)

geekoid (135745) | more than 2 years ago | (#39357399)

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.

LOL (1)

SuperDre (982372) | more than 2 years ago | (#39356199)

And to think that 90% of the software created by the government is actually created by commercial companies.. so the study is actually bogus...

Not the contractors fault. (0)

Anonymous Coward | more than 2 years ago | (#39356267)

Maybe the government just needs to add, "Must conform to X standard." in their contracts. If no standard is specified in the contract the contractor has no obligation to conform. This is an oversight by the government, not the contractor. What we need are knowledgeable people writing the contracts, not some bureaucrats buddy who donated some money and only knows how to write Hello World to a console..

uninstall (1)

profaneone (316036) | more than 2 years ago | (#39356325)

/me uninstalls SELinux.

shit from suger (2)

Stonefish (210962) | more than 2 years ago | (#39356393)

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.

Re:shit from suger (1)

geekoid (135745) | more than 2 years ago | (#39357439)

" One is that all government code is outsourced, actually its not.
um, no most of it is. And in my experience, at the end of the day it's more expensive then keeping staff on hand.

Interesting, Me experience is quite the opposite. Results make the next position you apply for more likely to look at you.
When you can get shit down,l people know and don't hire you, and eventual you position will be cut.

Security vulns are not bugs (1)

onebeaumond (1230624) | more than 2 years ago | (#39356445)

Veracode isn't offering to fix "buggy" code, they're selling "cyber terror" fixes.

The software in question usually called "laws." (1)

gestalt_n_pepper (991155) | more than 2 years ago | (#39356463)

Conceived by unaccountable committees. No independent cost/benefit analysis, no human factors or usability analysis. No testing prior to rollout. Spotty or no technical support. No GAAP accounting to see if the software saved money or accomplished stated goals. No money back guarantee and many of the developers leave the company every four years.

Bad metrics all around (1)

minstrelmike (1602771) | more than 2 years ago | (#39356775)

None of those percentages 16-28% sound very good to me.
The reason the govt is the worst is what others mentioned--too many cooks spoiling the broth.
The Department of Homeland Security consists of 22 separate Agencies that report to 88 different Congressional committees.That last sentence is a problem statement in my opinion.

Re:Bad metrics all around (1)

geekoid (135745) | more than 2 years ago | (#39357319)

Instead of agreeing because it confirms to your bias, look at where this 'study; comes from.

And the divsion of responsibilities in a government agency's is a strength, not a flaw.

Not only the US government (1)

tsa (15680) | more than 2 years ago | (#39356851)

Our (Dutch) police have a new computer system that is so bad the consensus is now to abandon it and start again from scratch. It has cost lots of hundreds of millions of euros.

Re:Not only the US government (1)

tsa (15680) | more than 2 years ago | (#39356871)

Replying to myself I know, but I forgot the other debacle: our new train ticket system which is very buggy, insecure and has also cost loads of taxpayer's money.

Re:Not only the US government (0)

Anonymous Coward | more than 2 years ago | (#39357173)

If only our bright folks at the ministry of transportation would have looked at other cities around the world with public transportation and RFID, they wouldn't have had to reinvent the wheel. (..again) And why does every transport company use different readers? No wonder it's buggy as hell. I'm surprised it even works. Barely.

Study Shows Increased Sales For Veracode (3, Interesting)

sweatyboatman (457800) | more than 2 years ago | (#39356921)

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.

insecure = buggy? (0)

Anonymous Coward | more than 2 years ago | (#39357201)

since when? buggy = insecure, I might agree with, but the fact that gov code did not score high on some arbitrary web security standards (not the ones that the contractors were being paid to implement, does not mean the code was buggy.

There's a number of reasons for this (2)

Tridus (79566) | more than 2 years ago | (#39357269)

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.

Yet another flawed studiy (2)

geekoid (135745) | more than 2 years ago | (#39357307)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?