Secure Development Methodologies Overview

Over the last few months, this blog series has focused on the technical details of integrating security during the development phase. While this is the most critical phase, where the proverbial rubber meets the road, developers alone cannot bear the burden of producing secure code. To achieve robust security, it must be integrated into the whole software development lifecycle, from requirements to testing and beyond.

There has been a lot of work in this space recently. This post will attempt to give an overview of the various methodologies and approaches, but it is not designed to be an exhaustive list (and is shown in no particular order).

• DHS Build Security In - This is a government effort led by the Department of Homeland Security, and they have a very solid (though somewhat dated) overview of the secure development methodology space, with a particular focus on incremental improvements (much more practical than "big bang" drastic changes in most organizations). In collaboration with Mitre, the Build Security In effort also releases a list of the top 25 software development errors, which complements the OWASP Top 10 list.
• Microsoft Security Development Lifecycle (SDL) - Microsoft was one of the first corporations to publish a secure development methodology, which many say was created largely in response to persistent vulnerability problems in Microsoft's operating systems. Today the SDL is used for virtually all Microsoft product development and has also been adopted by a number of third parties. Many other large corporations have followed suit, implementing their own in-house secure development methodologies tailored to their specific products--examples include Cisco, Apple, and Adobe.
• Building Security In Maturity Model (BSIMM) - Recently, the trend has been towards so-called "maturity models," which provide organizations the tools to evaluate their current maturity level and then make incremental improvements to reach higher maturity levels. BSIMM is based on real-world observations of best practices in secure development, unlike many other models which are more theory-based.
• OWASP CLASP (dated) - This model has not been actively maintained recently (OWASP is moving towards SAMM instead, see below), and it is also considerably less user-friendly than others. However, it serves as a good example of the evolution that has taken place in the secure development methodology space in the last few years.
• Software Assurance Forum for Excellence in Code (SAFECode) - SAFECode is a non-profit organization focused on researching and advancing software assurance techniques. They published an excellent paper summarizing the best practices in secure development as of November 2008, and this document remains highly relevant despite being nearly two years old. It's one of the most approachable and user-friendly guides to secure development that I have come across, especially for a less technical audience.
• Software Assurance Maturity Model (SAMM) - This is OWASP's latest secure development methodology, and in my opinion one of the better ones. It strikes a good balance between being comprehensive and technical but also approachable, and I find it one of the easier methodologies to translate into concrete action.

With all of these methodologies (and many more), it's hard to know which one is right for your organization. While they all share many of the same basic principles, they vary widely in their scope and approach to the problem. To keep things manageable, I have decided to use SAMM as the basis of my next series of blog posts, where we will be discussing the role of security in the various stages of the development cycle.

Next time, I will provide an introduction to and overview of the SAMM model, along with a rough outline of the blog topics we will be exploring in this space.