Slashdot Mirror
Holding Developers Liable For Bugs
sebFlyte writes "According to a ZDNet report, Howard Schmidt, ex-White House cybersecurity advisor, thinks that developers should be held personally liable for security flaws in code they write. He doesn't seem to think that writing poor code is entirely the fault of coders though: he blames the education system. He was speaking in his capacity as CEO of a security consulting firm at Secure London 2005."
I will admit that I have seen a lot of bad programmers and bad code over the past few years, but let's step back and think about this. Programming jobs are rapidly being sent overseas to India and China. This is not going to create much of an incentive to keep such jobs in the States, nor does it create much of an incentive for people to go into the field. Holding companies accountable, as suggested in the article, might be a slightly better solution, but again it's somewhat complicated when you start trying to hold an overseas company accountable. (It's more doable than holding an overseas individual accountable, but still not a simple task).
As for the article's last point about CMM environments: It's not at all an indication that software has been developed by quality developers, all it means is that the code was developed using a reasonable development framework. CMM level 3 means that you document your processes, and typically have peer review. Bad peers means peer review is worthless - it does not guarantee good programs. CMM Level 4 involves"quantitative quality goals" by which productivity, quality and performance are to be measured. This is a bit better, but again it's a matter of where the bar is set. CMM Level 5 is about continual improvement, and is extremely strict. I think that CMM Level 5 is the only environment where one can actually be assured of reasonable quality code. I've seen way too much bad code come out of CMM-3 and -4 environments to give them much credit. If you've got great people, then a CMM-3 environment typically produces great results. For -3 and -4, what you put in is what you get out - not guaranteed greatness.
About this little thing called "the mosquito" which we received as part of Earth v1.0....
Whatever happened to holding the people who exploit vulnerabilities responsible?
steampunk web design
You need proper code reviews, etc. if you want to find security flaws. The company writting the code should be responsible for organizing such things.
Facts do not cease to exist because they are ignored.
Remind me not to work for this guy.....
Why not make CEO's personally liable for not putting the code through proper QC channels and selling it over-promised.
Made to sell, not to use? Who's fault is that?
B-)
A friend will come and bail you out of jail, a true friend will be sitting next to you saying, "damn that was fun!"
CMMI doesn't guarantee good practice any more than membership in the Better Business Bureau guarantees good business. But I'd rather work in a shop that has CMMI in place than one that doesn't. It's insurance against the sort of death marches that create slapdash practice, shoddy product, and security holes in the first place.
I am currently the Development Lead / System Architect at my company. In my experience, the majority of "issues" and or "bugs" that I have seen crop up have been directly tied to poor requirements gathering by our "Business Analysts".
Often, it turns into a real pissing contest between the two groups. Usually, after testing reveals that the grand vision of the BA is a crock we will usually revert back to the original recommendation of the development group.
Yeah, let's blame the developers for the problems. That's the ticket.
When you die, on your deathbed, you will receive total consciousness. So I got that goin' for me, which is nice.
He doesn't seem to think that writing poor code is entirely the fault of coders though: he blames the education system.
You know, I don't think it's entirely his fault that he's an idiot: I blame the education system.
No kidding! If a car manufacturer produces a car that has a faulty part, is the engineer held laible? Hell no! its the company. You don't hear John Doe recalling the cars. Its GM that recalls it. Whether John is fired or not is a different issue and up to the company. Similarly the Software company is liable for the product. You blame Microsoft (sorry it was an easy target)!
While individuals can make stupid mistakes, the real problem is in the system and managers are ultimately responsible.
As a simple example, take a web application. The web people believe (reasonably or not) that the form fields will be cleaned up by the backend people. How do they know what's dangerous anyway? The backend people believe (reasonably or not) that the data will be cleaned up by the web people. How do they know the various encoding schemes used, etc.
Then some **** adds a cross-scripting exploit and compromises sensitive information.
Who's responsible, the developers or the managers? Even if the developers are paranoid, what about the errors introduced as everyone tries to handle conditions outside of their sphere of knowledge? What about the new security flaws introduced by that?
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
We hold them liable for defects that cause people to get hurt.
If you're going to attempt to compare apples and oranges, let's at least use an orange colored apple, shall we?
It'd be like holding car manufacturers liable for not making a car absolutely impossible to break into.
Hold the vendors responsible. They are responsible for 100% of all problems that are not the fault of the customer.
The vendor then holds the devloper responsible. They are responsible for 100% of all vendor bugs that are not the responsibility of the vendor.
The developer then holds the programmer responsible. He or she is responsible for 100% of all developer bugs that are not the responsibility of the developer.
It's the way it works everywhere else. If you have a faulty product, you take it back to the shop. They then take it back to the manufacturer and if it's a fault caused by a specific individual, they either sack him or train him properly. The purchaser would generally not sue the guy on the production line or the designer, even if it was their fault.
There are good reasons for doing things this way. It preents people from passing the buck. It means each entity along the line is wholly responsible for ensuring quality.
Few people on this planet can afford software developed to such a standard.
There will always be a market for "cheaper" software that is not guaranteed to such a level, and with support contacts instead, where developers will try a moderate ammount to fix problems as they arise.
From another perspective, the market is demanding of cheap software - not good software, which is why there is so much of it.
Sam
blog.sam.liddicott.com
Processes can aid in ensuring consistency, but they aren't strictly necessary.
I worked as a development/support programmer in a fairly critical application area for a major airline for over ten years, and we had a small tight team of a dozen fairly experienced developers and only a few formal processes in place. The software that was written and loaded in production was generally of very high quality, mainly due to a good culture of informal peer review, testing (involving users and programmers alike), heavy use of a test system to let changes simmer a bit before release, etc., but there really wasn't a formal "metholodogy" in place, just common sense practices that everyone there had agreed to follow.
For larger groups or in development environmments where software is released in bursts (e.g., a new version is released to external customers every few months) it might make more sense to put more formal processes in place, but when working on a living system that has to change from time to time in a few days (or even hours) I'd rather put my faith in a couple of experienced programmers who know the system and the expectations of the end users.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
1. You cannot become a doctor without long theoretical and practical training, intermixed with hard exams. All this is heavily regulated. To become a coder, you just have to pass a job interview. Software engineering certifications are optional and generally regarded worthless.
2. Doctors are insured against malpractice. The costs are high, and generally passed on to patients.
3. Doctors can choose not to operate (administer drugs, etc.), if the action constitutes malpractice. In software industry it's "use this braindead tool, or get fired".
4. Malpractice. Ok, today's revolutionary therapy, maybe tomorrow's malpractice (or vice versa), and experts might disagree about some practices, but there is some sort of general agreement on what constitutes malpractice. I'm not sure whether IT is mature enough to speak of "malpractice" here.
To sum it up: yeah, you can make developers liable for their mistakes, but the consequences would be huge. The costs of IT would skyrocket. Are you ready to pay for that?
Exactly. If a software makes $1 million. Do the developer(s) get the million? Then why should they be held responsible for the "loss" and not profit?
"There is no flag large enough to cover the shame of killing innocent people."--Howard Zinn
Programmers are not a parallel to automotive makers; they are a parallel to Authors, Book writers. Can you think of anything more absurd then suing an Author of a book over typos? Or the reviewer of that book who says "this is the best book of the year" and you thought it was the third best?
This is the same reason patents on software are ridiculous, can you patent a love story plot? It's just absurd. This is another example of our society's run-away liberal government mentality. Big government stifles creativity, freedom, and crushes capitalism.
A case like this should be thrown out of court as a frivolous lawsuit and the lawyer held in contempt, but we won't get that from activist judges.
Under oath, Clinton was given a very specific definition of sexual relations, and according to that definition he didn't have sexual relations with Monica Lewinsky. Where he did lie was to turn around and say the same thing to the American people. We didn't give him any such specific definition, so he should speak our language.
If Ford has a car with faulty steering that locks and causes me to be in a very bad accident, should Ford be liable? IMO, yes. Should the engineers be personally liable? IMO, no. It is up to Ford and their management to hire competent employees and competent management to make sure those employees put out a safe product.
Imagine what would happen if people were allowed to sue an individual employee because of a faulty product. The cost of labor for _any_ technical job would go through the roof because those, engineers, developers, machinists, etc would all need to buy personal liability insurance, just like doctors have to. One of the reasons doctors _have_ to charge so much here in the USA is because of insurance costs to protect them against sue-happy lawyers and people. Top surgeons can easily pay $100,000+ a year just for insurance!
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
I agree 100%. I think all companies should be liable for their products. However, I do not think it should be at the individual employee level.
Here's an interesting question. A piece of software that is written to work with Windows has a security flaw in it. The security flaw creates an exploitable condition in Windows such that you can gain total control over the system. Who's fault is it?
Obviously there was a security flaw in the software that you were using, but then it wouldn't be that critical if Windows handled it's security better. So isn't Windows partially to blame. And what if you set it up in an insecure manner? Isn't that your fault? Or is the developer's fault for not making it more idiot proof.
Now taking that down to the code inside of a program is just ridiculous. If you've got a team of 10 people (which is small in the grand scheme), each one of them could, individuall write totally secure code. However, come integration time, it turns out that they are opening up holes in eachother's code. So then who's fault is it? What about QA? Shouldn't they have some liability too?
Finally there's the PHB factor. You could have a group of the best, most security knowledgeable programmers in the world, and they could still screw up due to lack of time and resources. What if the boss tells them to do something that makes the system innately insecure? Who's fault is it then, his for telling them to do it or theirs for not pushing back on the requirement. Not to mention what happens after people have work a few months of 60 hour work weeks trying to get a project done.
In the end, liability is just a dumb concept in computers. In the end this is one of those places where the invisible hand of the market place is the best correction. Companies that write buggy software routinely will be smacked by the marketplace, by and large. The only exception to that rule is companies like Microsoft who have an effective monopoly. But then that's why we have anti-trust law isn't it?
This sig has been temporarily disconnected or is no longer in service