eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.)
[WP_IMAGE]
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.