Secure Development - Introduction to SAMM

Over the course of the next several months, this blog will explore the Software Assurance Maturity Model (SAMM) in detail. Last time, we talked about some of the many methodologies for integrating secure practices into the development cycle, but in the interest of keeping it simple we will be focusing on SAMM going forward.

First, a quick introduction to SAMM: according to its creators, SAMM is "an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization." The model is based on the following three premises, which ensure that it is realistic and flexible:

1. An organization’s behavior changes slowly over time
2. There is no single recipe that works for all organizations
3. Guidance related to security activities must be prescriptive, actionable, and measurable

The model is divided into four business functions: Governance, Construction, Verification, and Deployment. Each business function is subdivided into three security practices, for a total of 12 security practices. Within each security practice, there are three defined levels of maturity, with guidance on how to move up to each next level. The full outline of the model is as follows:

1. Governance
   1. Strategy & Metrics
   2. Policy & Compliance
   3. Education & Guidance
2. Construction
   1. Threat Assessment
   2. Security Requirements
   3. Secure Architecture
3. Verification
   1. Design Review
   2. Code Review
   3. Security Testing
4. Deployment
   1. Vulnerability Management
   2. Environment Hardening
   3. Operational Enablement

For more details, feel free to browse the online version of SAMM, or download the full PDF version for offline reading. Strangely enough, the online version (which I find more user-friendly, especially for quickly browsing through the model) is not directly linked from the main OpenSAMM page. To save you some searching, I have included the direct link to its page on the OWASP wiki at the beginning of this paragraph.

In the coming blog posts, we will examine each security practice in detail, providing practical advice on integrating SAMM best practices into the development lifecycle. As applicable, we will also tie these practices back to their corresponding OWASP Top 10 vulnerabilities.

One last thing you may be wondering: why rehash a well-documented model in a blog series rather than letting it speak for itself? The key here is making the model approachable for managers, developers, testers, and everyone in between. Most of our readers may have otherwise never have heard of SAMM...much less would they have the time to read the entire model and understand how it relates to their daily development activities. This blog series will pull out the highlights, give practical real-world examples, and generally serve as a sort of "Cliff Notes" version of the model for busy IT professionals.