Today is a very exciting day for software security. The CWE/SANS Top 25 Most Dangerous Programming Errors is being released. I was one of the 41 contributors to the Top 25 Errors.

The list of possible programming errors that can end up causing a vulnerability in an application is immense. The MITRE Common Weakness Enumeration (CWE) has grown to 700 entries. They are all valid programming errors but some are so obscure or low severity that it isn’t even worth inspecting for them in most software. When a list grows big often times the important items get diluted.

From my consulting days at @stake I learned that my customers didn’t want an exhaustive list of everything that could be a problem in their software. They only wanted to know about the things “worth fixing”. This is where some judgment comes in. You have to weigh the threat space: what weaknesses are getting exploited by attackers, and the severity: what weaknesses, if exploited, are likely to cause a serious security breach.

The Top 25 Errors are the flaws so prevalent and severe that no software should be delivered to customers without some evidence that the software does not contain these errors. Customers should start demanding that evidence today.

The first good news is a group of software security experts agreed to a list of the Top 25. The second good news is these issues are well understood and the list comes with advice on how to avoid these errors and fix them when discovered. I also learned from my consulting days that no one wants to hear about problems without a solid plan to fix them. I am also happy to report that a significant majority of these problems can be found using automation: either static or dynamic analysis.

Veracode has been focused on finding the security weaknesses that matter the most to our customers whether they are enterprises like financial services companies deciding on what software to purchase or software vendors striving to produce better software. We have always focused on finding the problems that are “worth fixing” and considered the rest noise. Veracode’s automated testing services are able to test for 64% of the Top 25 programming errors today. We are certain we will be able to raise that percentage in the future. Yet, it will be impossible to reach 100% with technology alone so there is a real need for developers and testers to understand how to avoid and discover these problems.

The ideal as I see it is for developers and testers to be trained on the Top 25 programming errors, for automation be brought to bear on finding as many of the Top 25 as quickly and easily as possible, and for humans to focus on manual inspection and testing to fill the gap. Then customers need to demand evidence that the Top 25 has been eradicated from the software they use and purchase. Here is the list:

CATEGORY: Insecure Interaction Between Components

  • CWE-20: Improper Input Validation
  • CWE-116: Improper Encoding or Escaping of Output
  • CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
  • CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
  • CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
  • CWE-319: Cleartext Transmission of Sensitive Information
  • CWE-352: Cross-Site Request Forgery (CSRF)
  • CWE-362: Race Condition
  • CWE-209: Error Message Information Leak

CATEGORY: Risky Resource Management

  • CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
  • CWE-642: External Control of Critical State Data
  • CWE-73: External Control of File Name or Path
  • CWE-426: Untrusted Search Path
  • CWE-94: Failure to Control Generation of Code (aka 'Code Injection')
  • CWE-494: Download of Code Without Integrity Check
  • CWE-404: Improper Resource Shutdown or Release
  • CWE-665: Improper Initialization
  • CWE-682: Incorrect Calculation

CATEGORY: Porous Defenses

  • CWE-285: Improper Access Control (Authorization)
  • CWE-327: Use of a Broken or Risky Cryptographic Algorithm
  • CWE-259: Hard-Coded Password
  • CWE-732: Insecure Permission Assignment for Critical Resource
  • CWE-330: Use of Insufficiently Random Values
  • CWE-250: Execution with Unnecessary Privileges
  • CWE-602: Client-Side Enforcement of Server-Side Security
Veracode Security Solutions


Security Threat Guides

About Chris Wysopal

Chris Wysopal, co-founder and CTO of Veracode, is recognized as an expert and a well-known speaker in the information security field. He has given keynotes at computer security events and has testified on Capitol Hill on the subjects of government computer security and how vulnerabilities are discovered in software. His opinions on Internet security are highly sought after and most major print and media outlets have featured stories on Mr. Wysopal and his work. At Veracode, Mr. Wysopal is responsible for the security analysis capabilities of Veracode technology.

Comments (3)

Tejeddine Mouelhi | January 19, 2009 5:26 am


It is interesting to see that you consider only two ways to perform security testing: automated tool, and manual penetration testing.
Why don't you consider semi-automated emerging tools like those based on JUnit, like for example JWebUnit, Selenium etc, which provide a good framework for writing security tests.

Automated tools are not efficient for detecting subtle flaws (i suggest reading this interesting study about the limitation of automated tool - ).

On the other hand, penetration testing can help detect flaws. But that really depends on the expertise of the tester, and when done manually it cannot be covering all parts of the code (consider large web apps), and will only reveal a small piece of existing flaws. I can see that this good enough for vendor, to say that they were able to find many flaws, but does that offer any guarantee of the absence of other flaws ?

A good trade-off between the two approaches, would be to use semi-automated tool, to manually write tests but helped by good framework.

I looking forward to read you opinion on this, as a security expert.

Kind regards,

Tejeddine Mouelhi | January 31, 2009 5:37 am

I was looking forward to have an answer to my point. I will go with thinking that I was absolutely right about what I wrote in my previous post and there was nothing you can argue about. Good for me!
I thought the point of writing this blog is to discuss interesting subjects with the security community and not only to advertize about your company.

Best regards,
Tejeddine Mouelhi,

cwysopal | February 2, 2009 1:15 pm


I agree with your approach. There is more to finding security vulnerabilities then just automated static and dynamic analysis. I mention them because these are approaches people are using today to find vulnerabilities cheaply and easily and are a great starting point yet usually not sufficient.

I wrote a book, "The Art of Software Security Testing", which taught traditional QA testers and developers how to use the tools and techniques they already have at their disposal for finding non-security bugs and repurpose them for security bugs. I think test harnesses and unit testers fall into this category.

While I think this is a good approach I am not holding my breath. Most organizations have not invested the time and resources to build up and train an internal security testing group or trained their QA people on security testing techniques. For them using automated tools can be a great start to tackling the problem of shipping software containing the CWE/SANS top 25 programming errors. As an organization matures they can get better at more semi-automated and manual techniques.


Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.