June 9, 2022

Last Updated on January 19, 2024

To help coordinate software security processes within the software development lifecycle (SDLC), more and more development teams will need to leverage the NIST 800-218 Secure Software Development Framework (NIST SSDF). This robust model—soon to be mandated across the US government software supply chain—was created to assist developers in establishing and maintaining secure development practices.

However, the SSDF and similar secure development frameworks (e.g., the BSA Framework for Secure Software, Building Security In Maturity Model (BSIMM) or the Microsoft Security Development Lifecycle) are not designed to quantify the maturity of the development processes or determine whether all possible secure methods are in place.

To address this potential gap in secure development strategy and methodology, OWASP maintains the community-led, open-source Software Assurance Maturity Model (OWASP SAMM). First released in 2009 and widely proven to improve secure software practices in diverse orgs worldwide, the model is now at Version 2.

Drivers for using OWASP SAMM

According to OWASP, “The Software Assurance Maturity Model (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.”

SAMM was originally constructed with the SDLC in mind.  Version (1.5) of SAMM is mapped to the NIST SSDF. The newest version of SAMM (2.0) is mapped to other widely accepted standards, all of which can be used to enhance your organization’s software security program.

OWASP says, “OWASP SAMM supports the complete software lifecycle, including development and acquisition, and is technology and process agnostic. It is intentionally built to be evolutive and risk-driven in nature.”

Some of the ways OWASP SAMM can help development teams—and software buyers—include:

  • Evaluating an organization’s existing software security practices
  • Building a balanced software security assurance program in well-defined iterations
  • Demonstrating concrete improvements to a security assurance program
  • Defining and measuring security-related activities across an organization

Strengths of OWASP SAMM

OWASP understands that putting a new security framework in place across your SDLC is not a trivial task, and that no model can be one-size-fits-all. What makes SAMM valuable is it’s straightforward to understand, discuss and plan around. It’s also flexible enough to be adapted to a wide range of environments from startups to large, multi-team enterprise DevOps groups.

Another great thing about OWASP SAMM is, it’s free!

OWASP SAMM Constructs

The SAMM model is organized around five essential Functions: Governance, Design, Implementation, Verification, and Operations. Each of these functions then has a series of Practices that apply to that Function. These are typically subsets of the primary function that help define the maturity of each function overall.

Within each Practice, SAMM further defines two discrete Streams. Stream A is typically associated with early practice definitions or identification, while Stream B is associated with upkeep and change over time.

For example, one of the Functions in OWASP SAMM is Governance. According to SAMM, “Governance focuses on the processes and activities related to how an organization manages overall software development activities.”

Governance contains three separate security Practices: Strategy and Metrics, Policy and Compliance, and Education and Guidance. Looking specifically at Education and Guidance, there are the two Streams. Stream A is Training and Awareness, which involves a direct initial action to place members of an organization “on the same page” as far as security goes. Steam B, Organization and Culture, is about maintaining a secure environment through ongoing action and encouragement.

Each Stream also has three Maturity Levels, which is ultimately what SAMM encourages teams to use to calculate the overall maturity of their security policy, processes and procedures. Each maturity level contains more in-depth requirements, so meeting level 1 is often a prerequisite to meeting level 2, and then level 2 is a steppingstone to level 3. This helps build clear direction on ways that an organization can develop and mature over time.

What’s Next?

If you’re developing software for internal and/or external use, your code probably embodies significant intellectual property (IP) and is possibly what differentiates you competitively. Failing to secure these assets is like playing Russian Roulette with your company’s future.

Yet despite more outsourcing and remote working than ever on dev teams, with more of the SDLC than ever taking place beyond in-house servers and firewalls, many companies have little to no focus on securing their code repos, test environments, etc. Applying security best practices to the code itself is also an afterthought for a high percentage of companies in all but the most heavily regulated industries.

If you’re concerned about the security of your source code and/or want to reduce vulnerabilities in your running application(s), contact Pivot Point Security to speak with an expert about putting software security best practices in place.

Did you know that application security is a team sport? This podcast explains how your team can win at the web app security game: EP#19 – Jim Manico – Why Application Security is a Team Sport and How Your Team Will Win