This year's Top 25 list adds an interesting dimension to the list that was published last year, which we covered here. Instead of simply listing the top 25 most dangerous security bugs, the new list provides profiles that make it possible for developers to focus in on the select parts of the Top 25 lists that are most relevant to their business.
They also published information on how to help mitigate and even eliminate entire classes of weaknesses. Thomas Claburn writes more on the list in his story.
In an unexpected twist, the group also published contract language organizations can consider using when buying custom development services. The goal of the language is to set down secure development expectations. Here's how they describe it:
The development of code using sound security practices is more effective than attempting to address security after the code has been written. This document is one part of a comprehensive initiative to provide buyers and users of software with the knowledge and tools to prevent the implementation of non-secure computer code, and, consequently, reduce the risk that applications based on that code will be vulnerable to attack. The language in this document will assist those who procure custom software by facilitating the identification of roles of code writers, and outlining their responsibilities for checking code and fixing security flaws before software is delivered.
This document is complemented by a second project, called the CWE/SANS Top 25, which identifies and prioritizes the programming errors that are most likely to cause security problems (www.sans.org/top25). In addition, a third project, the GIAC Secure Software Programmer assessments, is intended to permit employers and those who procure programming services to more readily determine whether programmers possess the necessary training and skills to write secure code. (www.sans.org/gssp)
Anyone who has been reading this blog for the past couple of years knows that I don't think there's a more important topic in IT security than the challenge of trying to secure the bug-ridden applications we are all saddled with every day. And just as I wrote two weeks ago in National Cyber Security: Are We Focused On The Right Stuff? I don't know what the eventual answer will be that forces improved software development standards on the industry.
But I do know these issues need to be discussed, and that's one thing that's certainly going to come out of the MITRE/SANS efforts.
Ultimately, I suspect, software will finally improve as awareness improves - and end users demand secure code - and that's probably going to have to involve some level of contractual language and liability.
The Application Security Procurement Language can be downloaded in PDF from the NYS Office of Cyber Security & Critical Infrastructure Coordination (CSCIC) website.
What are your thoughts?