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

4 of 838 comments (clear)

  1. If anyone it should be the managers by metternich · · Score: 5, Interesting

    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.
  2. It's the system, not the individual by coyote-san · · Score: 5, Interesting

    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
  3. In the end, it's the people who create quality. by Richard+Steiner · · Score: 5, Interesting

    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.
  4. Re:CMMI by Directrix1 · · Score: 5, Interesting

    Isn't it weird how several people, in almost unison, just suddenly decided: "Hey software developers need to be held liable for bugs in their code." It makes you wonder about their backgrounds (read second paragraph). I'm sure this has nothing to do with open source software developers being financially incapable of being held liable for flaws in software they donated. On the other side, I do agree that closed source (AND ONLY CLOSED SOURCE) software makers should definetely be held liable, as there is no other means of recourse in the event of software failure. Whereas, open source license or not, spells out exactly what it will do, line-for-line, and you can either take it or leave it.

    --
    Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF