The 25 Most Dangerous Programming Errors

Hugh Pickens writes "The Register reports that experts from some 30 organizations worldwide have compiled 2010's list of the 25 most dangerous programming errors along with a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications. The 25 flaws are the cause of almost every major cyber attack in recent history, including the ones that recently struck Google and 33 other large companies, as well as breaches suffered by military systems and millions of small business and home users. The top 25 entries are prioritized using inputs from over 20 different organizations, who evaluated each weakness based on prevalence and importance. Interestingly enough the classic buffer overflow ranked 3rd in the list while Cross-site Scripting and SQL Injection are considered the 1-2 punch of security weaknesses in 2010. Security experts say business customers have the means to foster safer products by demanding that vendors follow common-sense safety measures such as verifying that all team members successfully clear a background investigation and be trained in secure programming techniques. 'As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,' the introduction to the list states and includes a draft contract with the terms customers should request to enable buyers of custom software to make code writers responsible for checking the code and for fixing security flaws before software is delivered."

Comments

Re:Yeah, right.

[Madsy]

Software does not fail, ever. It either works according to the specification, or it does not. Any attack vector or 'bug' is a fault with the program which has always been there. Bridges and other structures can't be made 100% secure, but software can and should. If a piece of software is not, then either it does not work according to the specification (as in, not finished), or it was deliberately made to be faulty. This is where your analogy breaks down. A well-formed program is 'invincible', but a bridge can never be, unless someone invents a material which is resistant to corrosion, shock, extreme heat/cold, and never gets tired.

In fact, since software cannot fail, ever, designing a well-formed specification and software following that specification exactly, is the only thing you can be responsible for as a software engineer. Since the very definition of "works according to specification" implies the absence of any vulnerabilities, is it really so hard to see why the blame is put on the software authors, in addition to the 'attackers'?

Feel free to ship unfinished software, or make it insecure on purpose. But then don't be surprised of the opinion customers and your peers hold for you.

Re:Yeah, right.

[timmarhy]

it was as if 1000's of OSS nerds cried out and then were silent.