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

7 of 284 comments (clear)

  1. Kettle = black; by LaughingCoder · · Score: 5, Insightful

    "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.
  2. it's all about EULA by Thud457 · · Score: 5, Informative
    That's ok, it's covered in the EULA -- the vendor's not responsible for anything. Since the developers are either employed by or are contractors for the vendor, they're similarly protected from any responsibility. So it boils down to caveat emptor -- test, test, and retest before accepting any software product.

    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

  3. Re:Why not?! by Anonymous Coward · · Score: 5, Insightful

    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.

  4. RTF-REAL-A from wired by dzfoo · · Score: 5, Informative

    The real article by Bruce Schnier is in Wired:

    http://www.wired.com/news/privacy/0,1848,69247,00. html

    Its more interesting than the sound-bite-full ZD-Net summary.

          -dZ.

    --
    Carol vs. Ghost
    ...Can you save Christmas?
  5. Re:Why not?! by cpuh0g · · Score: 5, Insightful

    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.

  6. Languages with buffer overflows need to be avoided by applecrumble · · Score: 5, Insightful

    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.

  7. I'll accept liability for the code by Todd+Knarr · · Score: 5, Insightful

    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.