Software Security Still More Art than Science, Says Veracode

 
 
P. J. Connolly began writing for IT publications in 1997 and has a lengthy track record in both news and reviews. Since then, he's built two test labs from scratch and earned a reputation as the nicest skeptic you'll ever meet. Before taking up journalism, P. J. was an IT manager and consultant in San Francisco with a knack for networking the Apple Macintosh, and his love for technology is exceeded only by his contempt for the flavor of the month. Speaking of which, you can follow P. J. on Twitter at pjc415, or drop him an email at pjc@eweek.com.
By P. J. Connolly  |  Posted 2011-12-27 Email Print this article Print
 
 
 
 
 
 
 

It's the time of the season where I clear my desk of press releases and whitepapers to make room for the year to come. Although I'm pretty good about herding stray paper into recycling bins, file folders and drawers, there are usually a few things that evade me unless I'm being particularly aggressive about my tidying up. The stragglers are those documents that catch my attention without necessarily demanding my immediate attention, and they can put up a fight.

One such publication is Volume 4 of Veracode's State of Software Security Report, which came out on December 7. I've stuck my nose into this report for the last three weeks and pulled it out again, in part because it makes for terribly depressing reading. (You can download a copy here.)

securecode

If only secure codiing was as easy as pressing a key, Veracode would have little to report; unfortunately, the opposite is the case.

The worst thing is that, at the end of 2011, commercial software remains prone to stupid security vulnerabilities such as buffer overflows and the existence of backdoors into the application. You'd think we would have learned in the last twenty years how to manage data in memory securely, but it seems those lessons have to be relearned at painful cost, year after year.Almost as appalling is the vulnerability of applications, from whatever source, to old-school tricks such as cross-site scripting, CR-LF injection and directory traversal. This stuff can't be tolerated, if only because the dangers of these have been so well known for so long. Sometimes I wonder if post-secondary programming classes even discuss securing code, much less insist on it.

Although I recognize that developers are at the end of a very long food chain, they're also the only people who can implement security at the code level, no matter what methodology is used. It's time for coders to start treating secure coding as their lifeline to their next job, no matter the truth of the statement that between cheap, fast and secure code, you can only have two of those.

But there is one glimmer of hope as the year winds to an end: I was glad to read that Veracode's started grading software in a tougher fashion than previously, because it's clear that security remains a low priority for developers. I don't believe it's due to anything more than laziness, but sloth will screw things up almost as well as actual malice can.

It's not all on developers, of course; management has to be willing to pay the extra costs involved in creating secure code, whether those appear in the design, testing or deployment phases. Cutting corners on this is like playing cards at a casino, except that the stakes are much higher.

 
 
 
 
del.icio.us | digg.com
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel