Yesterday SANS/CWE released a list of the Top 25 Most Dangerous Programming Errors. They're really potential security issues - thus the "dangerous" part.

The list includes dot-com-era hits like Failure to Preserve SQL Query Structure (aka 'SQL Injection'), Failure to Preserve Web Page Structure (aka 'Cross-site Scripting') and Improper Input Validation. There are also more venerable errors like Race Conditions, and one that presumably pre-dates computers: Incorrect Calculation.

What is new and interesting is the proposal that "buyers [...] require that software vendors certify in writing that the code they are delivering is free of these 25 programming errors".

In general I think having a list of common errors is a good thing. Merely getting a list together will help spark dialogue, and, as the announcement notes, those who "prepare programmers will use the Top 25 Errors as a foundation for curriculum". My experience as a CS undergrad was entirely focused on design and implementation; debugging was something you had to figure out for yourself.

That said, I'm not sure how feasible it is for organizations to certify that they are free of the top 25 CWEs. The cost to do that by hand could be prohibitive in any economic setting. Nor is it clear that every buyer needs such certification, or would be willing to pay for the overhead.

What is needed now are code analysis tools to help pinpoint these types of issues. I've already written about Attivio's own practices with respect to quality - we use a variety of static code analyzers like FindBugs and CheckStyle and are always on the lookout for new ones. My perception, perhaps wrong, is that such tools are more prevalent today than they were 10 years ago. One company I worked for used Purify and BoundsChecker, but others didn't bother with them, or limited them to QA use.

The announcement mentioned that a "leading software testing vendor" will announce support for detecting a "large fraction" of the errors, but didn't name them. I haven't seen any specifics; if you have please This e-mail address is being protected from spambots. You need JavaScript enabled to view it or leave a comment.

I hope these kinds of announcements will serve as a rallying cry for the industry. And let's not stop at automated code analysis; at least one commenter on Slashdot argued convincingly that the problem is also (perhaps as much or more) rooted in the way companies approach software - packing features in until the release is late, or changing requirements on the fly - then releasing a buggy beta and hoping to clean it up in time for the release. Almost any methodology, followed even moderately, would likely produce a better result than that.

Building good quality software requires focused and deliberate efforts - from requirements to design, implementation to testing. Static code analysis and a productive methodology are just two more angles. There are no shortcuts.

TrackBack URI for this entry

Comments (0)