Application Security Maturity Models

A look at OWASP's Software Assurance Maturity Model (SAMM)

We’ve spoken a fair bit about secure software development and efforts to improve the overall security maturity of an organizations applications and software. In this article, we will in particular look at OWASP’s SAMM.

We’ve discussed emerging requirements in the U.S. Federal sector such as the Office of Management and Budget (OMB) calling for third-party software vendors to self-attest to aligning with NIST’s Secure Software Development Framework (SSDF).

As covered in that article, SSDF utilizes a myriad of existing industry sources, such as OWASP’s ASVS, BSIMM and OWASP’s SAMM when it comes to its specific practices, tasks and examples for secure software development.

For an example of the synergy between NIST’s SSDF and OWASP SAM, let’s take a look at a specific SSDF Practice, such as “Identity and Confirm Vulnerabilities on an Ongoing Basis” (RV.1) - in the Respond to Vulnerabilities area. You can see that it cites OWASP SAMM IM1-A, IM2-B and EH1-B among its references on the right.

Looking at models such as Building Security in Maturity Model (BSIMM) or Software Assurance Maturity Model (SAMM) can be very effective ways to document the maturity of a supplier’s software program or even internal software development efforts across organizational development teams.

When it comes to third-party software vendors, it should be noted that receiving a self-attestation of adherence for compliance should be taken cautiously, as it isn’t concrete evidence of true alignment with requirements, just take a quick look at the DoD Defense Industrial Base (DIB) who has seen several years of notable security incidents among vendors who have historically self-attested to NIST 800-171 security controls, which has now led to the push for 3rd party attestation through their emerging Cybersecurity Maturity Model Certification (CMMC) framework, much like FedRAMP’s use of a 3PAO.

However, as we have discussed in our article on FedRAMP, 3PAO compliance schemes come with their own challenges, most notably, scalability and severely limiting the body of vendors an organization/industry get access to, which isn’t always desirable.

This is also where other artifacts such as SBOM’s which show the software component inventory of applications/software and their associated vulnerabilities can be valuable, along with traditional technical measures such as vulnerability scanning and penetration testing.

All of that aside, the focus of this article is OWASP’s SAMM, so let’s dive in.

OWASP SAMM

OWASP SAMM, also known as OpenSAMM in prior versions. (https://owasp.org/www-project-samm/) aims to help organizations formulate and implement strategies for software security, and the project cites 4 key areas it can help organizations, such as:

• Evaluate an organization’s existing software security practices

• Build a balanced software security assurance program in well-defined iterations

• Demonstrate concrete improvements to a security assurance program

• Define and measure security-related activities throughout an organization

BSIMM is also widely used, but as it is a proprietary model, we will opt to examine open-source approaches, such as OWASP’s SAMM.

SAMM defines the following domains: 

Source: OWASP SAMM v2 Model (https://owasp.org/www-project-samm/)  

SAMM defines 5 business functions, as depicted in the image above, which are Governance, Design, Implementation, Verification and Operations. Within those business functions there are 3 security practices. Each security practice involves 2 streams of activities that complement and build upon one another. Since SAMM is an open model, it can be used internally to assess an organization, or by a third-party.

Like all OWASP projects, SAMM is a community-driven effort and aims to be measurable, actionable, and versatile. Unlike BSIMM, SAMM is prescriptive, meaning it prescribes specific actions and practices organizations can take to improve their software assurance. SAMM is, as the name states, a maturity model.

It ranges from levels 1-3 across the security practices it specifies, with an implicit starting point of 0. While SAMM is a maturity model, it does not state that all organizations must achieve the highest level of maturity across all practices. Maturity requirements and goals will depend on the organization's resources, compliance requirements, resources and mission sets. Each “Stream” has a corresponding maturity level ranging from 1-3, building on lower maturity levels and activities. See the example below:

Let us dive into some of the business functions and associated security practices within SAMM a bit.  

Governance

The first business function is Governance, which is focused on the processes and activities related to how an organization manages their software development activities. The practices involved include Strategy & Metrics, Policy & Compliance and Education & Guidance.

This involves creating and promoting strategies and metrics and then measuring and improving them over time. On the policy and compliance front, it involves creating policies and standards and then managing their implementation and adherence across the organization. Underneath Education & Guidance you have streams such as Training and Awareness, and Organization and Culture.

Training and Awareness focuses on organizations improving knowledge around software security with their various stakeholders and organization and culture is oriented around promoting a culture of security within the organization.  

Design

The second business function is Design, which focuses on processes and activities for how organizations create and design software. The security practices include Threat Assessment, Security Requirements and Security Architecture. Threat Assessment focuses on streams such as application risk profiling and threat modeling.

As part of profiling, organizations determine which applications pose serious threats to the organization if compromised and threat modeling, as we have discussed elsewhere is helping teams understand what is being built, what can go wrong and how to mitigate those risks.

Security Requirements involves requirements for how software is built and protected as well as requirements for relevant supplier organizations that may be involved in the development context of an organization's applications, such as outsourced developers. Security Architecture deals with the various components and technologies involved in the architecture design of a firm's software.

This includes the architecture design to ensure secure design as well as technology management which involves understanding risks associated with the various technologies, frameworks, tools, and integrations that applications use.  

Implementation

The third business function is Implementation, which involves how an organization builds and deploys software components and their associated defects. The security practices involved are Secure Build, which is consistently repeatable build processes and accounting of dependencies, Secure Deployment which increases the security of software deployments to production and Defect Management which involves managing security defects of deployed software.

The streams within the Secure Build practice are Build Process and Software Dependencies. The build process ensures you are deploying predictable, repeatable secure build processes. Software dependencies focus on external libraries and their security posture matches the organizational requirements and risk tolerance. The Secure Deployment security practice focuses on the final stages of delivering software to production environments and ensuring its integrity and security during that process.

The streams associated with this practice are the Deployment Process and Secrets Management. The deployment process ensures organizations have a repeatable and consistent deployment process to push software artifacts to production as well as the requisite test environments.

Secret management is focused on properly handling of sensitive data such as credentials, API keys and other secrets which can be abused by malicious actors to compromise environments and systems involved in software development. Defect Management is the last security practice in this business function and focuses on collecting, recording, and analyzing software security defects to make data-driven decisions.

The streams involved include defect tracking and metrics and feedback. Both involve managing the collection and follow-up of defects as well as driving improvement of security through these activities.  

Verification

The Verification business function is the processes and activities for how organizations check and test artifacts throughout software development. The security practices associated with verification are architecture assessment, requirements-driven testing, and security testing.

Architecture assessment validates the security and compliance for the software and supporting architecture while requirements and security testing based on things such as user stories to detect and resolve the security issues through automation. Architecture assessment has streams involved that include both validation and mitigation.

This means validating the provision of security objectives and requirements in the supporting architecture and mitigating the identified threats in the existing architecture. The testing streams under these practices ensure organizations are doing activities such as misuse/abuse testing to use methods such as fuzzing and others to identify functionality that can be abused to attack an application.

Security testing will involve both a broad baseline of automated testing and deep understanding that involves manual testing for high-risk components and complex attack vectors that automated testing cannot complete.  

Operations

The Operations business function ensures the Confidentiality, Integrity and Availability of applications and their associated data is maintained throughout their lifecycle, including in runtime environments.

Security practices include incident, environment, and operational management. Going further, streams encompass various areas such as incident detection and response as well as configuration hardening and patching.

Lastly, Operational Management ensures that data protection occurs throughout the lifecycle of creation, handling, storage and processing and that legacy management to ensure end of life services and software are no longer actively deployed or supported. This reduces organizations attack surface and removes potentially vulnerable components from systems and applications.  

By utilizing SAMM and covering the various Business Functions, Security Practices and Streams, organizations can get more assurance around their application security maturity, and the same goes for their software consumers who benefit from software suppliers maturing their software development practices.

OWASP provides a set of useful resources for organizations looking to use SAMM, such as a How-To Guide, Quick-Start Guide and a SAMM Tool Box. If you’re interested in digging deeper into the practices and associated details, be sure to check out the web or PDF versions of the full SAMM model. This will help you understand each Business Function, Security Practice, their associated Streams and Maturity Levels.

For example, the OWASP SAMM Toolkit provides a structured worksheet where organizations can capture and document their existing OWASP SAMM maturity levels across the various Business Functions and Security Practices and produce correlating scores to see how they measure up and where they have gaps they want to address.