Required Reading: TOP 25 Most Dangerous Programming Errors

Feb 1, 2009   //   by Karen Lopez   //   Blog, Compliance and Regulation, Data, Data Breach  //  No Comments

Error ISS Trainin Module SCAM-CE GHF-CE

The SANS Institute and the Common Weakness Enumeration (CWE) project released last week a list of the top 25 programming errors.  This resource, which lists the error and the project phases/tools/processes to which they apply, should be required reading, on a regular basis, by all team members on a development project. While this page refers to programming errors, I believe this is a great checklist of development errors, as some of them apply to architectural and methodological issues.

SANS Institute – CWE/SANS TOP 25 Most Dangerous Programming Errors

Experts Announce Agreement on the 25 Most Dangerous Programming Errors – And How to Fix Them
Agreement Will Change How Organizations Buy Software.

Project Manager: Bob Martin, MITRE

(January 12, 2009) Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.

The impact of these errors is far reaching. Just two of them led to more than 1.5 million web site security breaches during 2008 – and those breaches cascaded onto the computers of people who visited those web sites, turning their computers into zombies.

Even in 2009 I am constantly struggling with getting vendors and my own developers to acknowledge the importance of dealing with these issues.  As a project manager, I’m the one ultimately responsible for ensuring that delivered systems will do no harm, but that’s one of the hardest parts of my jobs.  Why?

  • Most of my newer developers have never received any formal education, training, or testing on many of these issues.
  • Many vendors rely on customer requests or customer production testing to identify these errors. 
  • Most packages, with anti-reverse engineering clauses in their terms of use, forbid inspecting code for these vulnerabilities.
  • Business users often don’t understand the short and longer term implications of neglecting these professional issues…nor should they have to.  But since we don’t have a "building code" or standards of practice in IT, we architects and project managers have no external authority to fall back on when users want to cut the security and protection steps of a project.
  • Many people still naively cling to the belief that the tools they use automatically protect them from these weaknesses.

Of particular interest to those of us working in the data and information responsibilities of a project are these development errors:

CWE-20: Improper Input Validation

It’s the number one killer of healthy software, so you’re just asking for trouble if you don’t ensure that your input conforms to expectations…MORE >>

I am constantly asked to allow the programmers to research and implement the validation rules for input data, since this cuts down on the amount of analysis needed and allows coders to get coding faster….and it always leads to less than acceptable validation, as coders don’t have time to go research the data — they need to be coding.  It’s a vicious circle.

CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)

If attackers can influence the SQL that you use to communicate with your database, then they can…MORE >>

This involves using the lowest level of authority required to get the job done, among other things.  Yet developers usually want to develop, test, and deploy while using administrator-level authority.  Code should not be tested while running under administrative authority since it should not be deployed that way, either.  It is amazing to me how many people tell me they *must* have the SA password in order to code.  They may need some administrative-like rights, but no-one needs the SA account to develop code.  Not even DBAs.

I work with a few vendors who tell me that their packaged application must run under the SA account and the Windows Administrator, in production.  No amount of discussion with their "lead developer" will change their minds. It’s pure laziness and cluelessness to design a product that requires these rights. I have convinced many a client to replace software (and therefore vendors) that require this type of authorities.

I find this list to be of sufficient importance that I’m recommending that teams schedule a specific effort to review, discuss, and create an action plan for addressing these items.

So go pour yourself a coffee/tea/cola/water and start reading.  Your customers will thank you.

Leave a comment

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to by Email



UA-52726617-1 Secured By miniOrange