Slashdot Mirror
Insecure Code - Vendors or Developers To Blame?
Annto Dev writes "Computer security expert, Bruce Schneier feels that vendors are to blame for 'lousy software'. From the article: 'They try to balance the costs of more-secure software--extra developers, fewer features, longer time to market--against the costs of insecure software: expense to patch, occasional bad press, potential loss of sales. The end result is that insecure software is common...' he said. Last week Howard Schmidt, the former White House cybersecurity adviser, argued at a seminar in London that programmers should be held responsible for flaws in code they write."
"the former White House cybersecurity adviser, argued at a seminar in London that programmers should be held responsible for flaws in code they write."
OK. And to make it fair, let's let lawmakers be responsible for all the unintended consequences their legislation brings about.
The more you regulate a company, the worse its products become.
Let's see: do we hold employees at an auto factory responsible when unrealistic timetables means shoddy workmanship, or do we hold the employer who chooses speed to market over quality responsible? If that failure means the death of someone, do we sue the manufacturer or the guy who made the poor weld?
Large software companies have more in common with factories than they do with law firms or medical practices, two places where the liability *is* on the individual. The employees don't get to choose how much time is spent designing quality and security into the product, nor do they get to choose how much quality assurance is done on the back end (although that is a lesser solution to quality code, it is still necessary).
The day that every programmer is licensed the way that doctors and lawyers are is the day I will reassess this position, but for now programmers are *not* in the position to make the decisions that lead to quality code. I'm not convinced that licensing would ensure that, but without licensing coders are nothing more that code churners cranking to the beat of the employers drum.
Sig under construction since 1998.
Too bad you have to click through the EULA before you can test it, suckers!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Next you'll be claiming that bad movies are the fault of the people making them, or that it's Britney Spears' fault she sounds like a howler monkey being run over by a bus.
Sheesh. Scientologists...
I'm sick and tired of hearing talk about holding vendors or developers legally responsible for writing insecure code. It's impossible to write any complex application and not have security problems.
The software industry operates more like the automobile industry: they know their cars will have problems, so they freely fix those problems for the warranty period. Software's warranty period is as long as the vendor or developer say they'll support that software.
The major difference is with closed source software, after the "warrany" period is up you can't usually pay someone to fix the problems. Open source provides a great car analogy, because after, say, Red Hat stops supporting your OS you can still fix it yourself or hire a developer to fix it for you.
This is why nobody would buy a car with the hood welded shut. For the life of me I can't figure out why anybody would buy software with the "hood" welded shut.
The global economy is a great thing until you feel it locally.
We're an exception because you pay us next to nothing and give us no time to work. You don't hire an engineer and then tell him to build a bridge in a few weeks.
Tell you what, I'll get licenced to write code and be legally responsible for it the day that customers are willing to pay about 8x what they current pay for the software, and can wait about 4x as long. Can you make that happen? I'm waiting anxiously, because *I* don't get to make those decisions.
So guess what...you want good code, hold the *EMPLOYER* responsible. I'll bet I suddenly find myself with all of the time I need to develop quality softare.
You'll notice also that this does nothing to improve the security of the code. It just makes it more expencive.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
As a software developer, I'll take responsiblity for bugs in my code and the damages they may cause, the day that politicians take responsiblity for their campain promises and the crap they end up passing as law later...
---
Programming is like sex... Make one mistake and support it the rest of your life.
The real article by Bruce Schnier is in Wired:
. html
http://www.wired.com/news/privacy/0,1848,69247,00
Its more interesting than the sound-bite-full ZD-Net summary.
-dZ.
Carol vs. Ghost
Really? If your car's engine has a problem, do you sue the machinist who made the faulty part or just sue his company? Individual engineers who work for a company that creates software are responsible within the company, but should not be exposed personally. The company takes the ultimate responsibility for the products they produce. If they shortchange the development cycle in order to rush to market and the product is crap, the company takes the hit, not the engineer who wrote the code.
I don't code, but I don't think making developers responsible for faulty code is a good solution.
If I develop X for a company that then takes X to market, and X turns out to be faulty, company should be at fault. I am at fault for writing shoddy code, the effect of which will be that I get fewer future contracts or employment to do the same. Company is at fault for taking X to market, and as such should be resonsible for any liability due to X's shortcomings.
GM is responsible for a shoddy part on one of its vehicles, not the engineer that developed the part.
Sole proprietors who take their code to market should be responsible, but in that instance, the sole proprietor is both developer and vendor.
un burrito me trampeó.
My point is, there's a whole range of "bad things" that happen, from clearly negligent to uncontrollable, and a lot of stuff in between, and we make that judgement every day by assessing or not assessing blame.
To construct large, complex software systems without bugs (including security flaws) is beyond the state of the art. In fact, it is beyond the state of the art by definition: if we could make today's systems bug-free, we could, and would, make even more ambitious systems by tolerating some rate of errors. Conversely, with today's state of the art, if we placed correctness (including security) above everything else, we'd have to cut way back on what we attempt, and charge a lot more. The market has already decided that's the wrong approach.
A good start to our current security problem would be to stop writing internet based software in languages that allow buffer overflows to occur (e.g. C, C++). 90% of security exploits are caused by buffer overflows. I've seen a figure like this in research papers, but it should be obvious to anyone from reading patch descriptions and current security alters. Writing computer programs in these types of languages and patching the errors as they are found is simply not a scalable solution. It essentially means that if you write a program to be used on a network, you have to maintain and patch it forever because you'll never catch all the buffer overflows it contains (e.g. the zlib bug, not a particular large library and it has been around for a long time). Picking a tool that doesn't even allow these types of errors is the obvious solution. In addition, we need to start using more granular security permissions for our programs. Blaming security problems solely on users is ridiculous. Could you explain to me why a program downloaded from the internet has read and write access to every file on my computer? Why it can open up network connections? Having root users is a start, but we need to be able to sandbox all the applications we download so they just aren't allowed to do anything bad. I see no reason why a user shouldn't be able to download and run any program they find, as they should all be sandboxed appropriately that they cannot cause damage.
As a programmer, I'll accept liability for bugs in the code... the day I get the same protection that a professional engineer gets: if I say I need X for the program to be properly designed/written/tested, any manager or executive or marketer who says otherwise can be thrown in jail. No mere job protection, no civil remedies, jail time for anyone who tries to overrule me, same as would happen to a manager who overruled the structural engineer's specification of the grades of concrete and steel to be used in a building.
Responsibility and authority go hand in hand. If they want to hand the the responsibility, they give me the authority to go with it. If, OTOH, they don't want to give me the authority, then they can shoulder the responsibility.
Who do you trust more?
... noted security expert or political hack, ... noted security expert of political hack?
Noted security expert or political hack,
It's not even close. On the credibility front Schneier has hundreds - no, thousands - of times more credibility on this issue than a political appoiontee out of the White House. Actually it's infinitely more credibility because anything times zero is zero where the White House is concerned.
Most contracts result in the company owning all of the intellectual property. If the programmer can't own their work, then the owner should be responsible for it.
Besides, it is a company's responsibility to sell good products. If they sell a product that is defective, it is often because they didn't do sufficient Q&A on the product, or rushed it to market.
Bottom line is that if a car maker sells a car with a defective part (the tires lugs were defective), and it passes shoddy Q&A, it is the maker's fault, not the assembly line guy. If it doesn't pass Q&A, you can be sure Ford won't sell it -- but the same doesn't seem true of software.
Yes, software has bugs and mistakes and errors, and in a large project it can become infeasible to guarantee that there aren't issues somewhere. That doesn't mean, however, that software should simply ignore the issue. It's a matter of contracts and assurance: It is possible to make certain assurances about a piece of software and spend the time making sure it fulfills those properties. For instance, while you might not go to the trouble of ensuring a word processor is completely bug free, it may be worth providing assurances, for instance, that files cannot be corrupted when the program crashes, and that the print preview is exactly what will be printed. There are methods for proving and verifying such properties, and if you restrict it to key properties that the client wants formal assurance on then it is not significant extra work to use those methods.
The same principle applies to security. While you may not be able to say your system in completely invulnerable without expending enourmous amounts of time and money, you can make certain formal assurances like "no buffer overflow exploits exist in this software" or "the software will always fully and correctly carry security protocol X, or abort with an error and deny access". Such things don't ensure 100% security, but being able to formally make such assurances does significantly improve the expected security of the software.
For some reason software has gotten stuck in an "all or nothing" mentality, claiming that obviously you can't ensure perfection, therefore you should assume nothing, and make no assurances at all. That is neither necessary, nor productive. Being able to formally guarantee certain properties of software is both possible, and only as much extra work as the amount of assurance you choose to provide.
Jedidiah.
Craft Beer Programming T-shirts
Because an Engineer of Real World Objects(tm) won't ever have to, say, open the bridge for traffic while the road deck is still being attached because someone decided it needed to be released early.
An Engineer wouldn't be told that we need flying butresses, a bike lane, and cantilevered sidewalks two weeks before the bridge is supposed to be open, but that it can't affect the delivery timeline and there's no time to test them, and no extra time to do the work so we'll have to do it in our own time.
Until such time as your employer builds in several extra weeks (months?) of testing for security, provides you with resources to do it, and brings in independant experts to help verify it, then it will be completely impossible for professional developers to meet that standard.
And as long as the company is selling the software with a license that absolves them from any blame, and helps to ensure they have that theoretically-perfect software, I'm sure as hell not putting my ass on the line with the ultimate responsibility for it.
Just because the company made several million, and the salesperson got a huge comission, doesn't mean that if it was rushed out the door for reasons out of my control that I got paid any more for the effort. Shit may run down hill, but no *way* it falls that far.
Lost at C:>. Found at C.