Securing SDLC with the OWASP Software Assurance Maturity Model (SAMM)

In the ever-evolving landscape of software development, security should be embedded into the fabric of the software development lifecycle. This is where the Open Web Application Security Project's (OWASP) Software Assurance Maturity Model (SAMM) comes into play.

The OWASP SAMM (version 2.0 released Jan 2020) is a community-driven framework that provides organizations with a flexible tool to help them implement, evaluate, and mature their software development security practices. It's designed to be technology and process agnostic, which means it can be integrated into any software development lifecycle (SDLC).

The model is structured around five main business Functions: Governance, Design, Implementation, Verification, and Operations. Each of these Functions is further divided into three Security Practices, which are subdivided into Streams. Each Stream of each Practice of each Function is described in three maturity levels.

What makes OWASP SAMM truly stand out is its Toolbox. The OWASP SAMM Toolbox includes tools in Excel, Google Sheets and SAMMY - a third-party tool by Codific - that assist organizations in implementing and assessing their software development security posture according to the SAMM. These tools allows organizations to measure their current level of maturity, define their target state, and track their progress over time. They include features for scoring, reporting, and benchmarking.

Closer look at the Model

Let's take a closer look at one of the Security Practices to really understand how the model and the Toolbox look and reinforce each other. Choosing randomly, let's take a look at Implementation (a Function), which has Secure Build (a Security Practice), which has Build Process and Software Dependencies (two Streams).

According to the SAMM documentation, Secure Build "emphasizes the importance of building software in a standardized, repeatable manner, and of doing so using secure components, including 3rd party software dependencies.

The first stream [i.e. Build Process] focuses on removing any subjectivity from the build process by striving for full automation. An automated build pipeline can include additional automated security checks such as SAST and DAST to gain further assurance and flag security regressions early by failing the build, for example.

The second stream [i.e. Software Dependencies] acknowledges the prevalence of software dependencies in modern applications. It aims to identify them and track their security status in order to contain the impact of their insecurity on an otherwise secure application. In an advanced form, it applies similar security checks to software dependencies as to the application itself."

In the below chart you can see how the two Streams are mapped to the maturity levels one through three.

Though you could try to figure out how to assess where your organisation stands based on the maturity model just by looking at the above mapping, the Toolbox makes life easier because it includes questions to enable the maturity assessment. There are questions for every single stream, practice and function, and the tool includes scoring and tallying mechanisms, as well as a nice-enough looking summary chart and graph.

So to wrap up, the OWASP SAMM and its Toolbox, are terrific tools. By using them, organizations can improve their secure development practices in a structured way; they can implement a maturity model tailored to their specific needs, which can serve as a roadmap for improving their application development practices over time. The SAMM provides a common language for comparing their program with peers, which can be invaluable for benchmarking and learning from others' experiences.