OWASP SAMM — Software Assurance Maturity Model

Why does it matter?

Security activities in a development organization are easy to list and hard to measure. SAMM exists to make them measurable: the project describes a model that is measurable through defined maturity levels across security practices, actionable through clear pathways for improving those levels, and versatile because it is technology, process and organization agnostic. Because there is no single recipe that works for all organizations, SAMM does not insist that every organization reach the maximum maturity level in every category; each one sets the target that fits it.

Key benefits include:

• A shared map of software security work

Five business functions and 15 security practices give every team the same vocabulary, from Strategy and Metrics in Governance to Operational Management in Operations.

• A score that can be repeated

Three maturity levels per practice, with quality criteria for every activity and an updated scoring model in version 2.0, let an organization measure coverage and quality and compare one assessment with the next.

• Targets the organization chooses

Each organization determines the target maturity level for each security practice that is the best fit for it, rather than meeting a fixed bar.

• Works with any development style

The version 2 model is development paradigm agnostic and supports waterfall, iterative, agile and DevOps, so the same assessment applies across teams that build differently.

• Free, open and tool-ready

The content is open under CC BY-SA 4.0, held in YAML files so tools and other consumers can use it automatically, and published on the SAMM website with incremental updates.

How does it work?

At the top level SAMM defines five business functions, each a category of activities that any organization involved with software development must fulfill to some degree. Governance holds Strategy and Metrics, Policy and Compliance, and Education and Guidance. Design holds Threat Assessment, Security Requirements and Secure Architecture. Implementation holds Secure Build, Secure Deployment and Defect Management. Verification holds Architecture Assessment, Requirements-driven Testing and Security Testing. Operations holds Incident Management, Environment Management and Operational Management.

Inside each practice, activities are grouped in logical flows and divided into two streams. Each stream covers a different aspect of the practice and has its own objective that is reached in increasing levels of maturity, which removes the orphan activities of the earlier model that seemed relevant at only one level. For each practice SAMM defines three maturity levels with a successively more sophisticated objective, specific activities and stricter success metrics; activities at a lower level are typically easier to execute and need less formalization than those at a higher level.

An assessment scores the organization's current posture across all business functions. Version 2.0 measures maturity from both a coverage and a quality perspective, with quality criteria for every activity and an updated scoring model for assessors and organizations. The organization then defines its target per practice, builds a roadmap in defined iterations, and uses the Getting Started guide and the SAMM Toolbox to run assessments and create roadmaps; the Benchmark initiative compares results with other similar organizations and teams.

Key Elements

• Governance

Strategy and Metrics, Policy and Compliance, and Education and Guidance: the practices that set direction, obligations and skills for the software security program.

• Design

Threat Assessment, Security Requirements and Secure Architecture: the practices that shape software before it is built. This function was called Construction in version 1.5.

• Implementation

Secure Build, Secure Deployment and Defect Management: the fifth business function, added in version 2.0 to represent core activities in the build and deploy domains, with Defect Management as a new practice.

• Verification

Architecture Assessment, Requirements-driven Testing and Security Testing: the function redesigned in version 2.0 that checks what was built against what was intended.

• Operations

Incident Management, Environment Management and Operational Management: the practices that keep software secure once it runs. Operational Management is new in 2.0 and Operational Enablement was removed.

• Two streams per practice

The activities of every practice sit in two streams, each with its own objective that is reached in increasing levels of maturity, so no activity is relevant at only one level.

• Three maturity levels

Level 1 initial implementation, level 2 structured realization and level 3 optimized operation, scored in version 2.0 for both coverage and quality against defined quality criteria.

• Toolbox, Benchmark and version mapping

The SAMM Toolbox performs assessments and creates roadmaps, the SAMM Benchmark compares maturity with similar organizations, and a published mapping shows how version 1.5 maps to 2.0.

What does it cover?

SAMM supports the complete software lifecycle and is technology and process agnostic: it was defined so that small, medium and large organizations using any style of development can customize and adopt it, and the project says its solution details are easy enough to follow even for non-security personnel. It is a self-assessment model, not a certification scheme, and it is prescriptive about activities rather than about products or tools. Whether an organization builds in a waterfall, iterative, agile or DevOps way, SAMM gives it a means of knowing where it is on its journey toward software assurance and what is recommended to move to the next level of maturity.

What are its objectives?

The project's mission statement and the description of the model's structure set out what SAMM is for:

To provide an effective and measurable way for all types of organizations to analyze and improve their software security posture.

To raise awareness and educate organizations on how to design, develop and deploy secure software through a self-assessment model.

To support the assessment of an organization's current software security posture and the definition of its target.

To support the definition of an implementation roadmap to reach that target, in defined iterations that show progressive improvement.

To give prescriptive advice on how to implement particular activities, so that organizations can define and measure security-related activities.

Framework in Context

SAMM descends from OpenSAMM 1.0, written by Pravir Chandra in 2009; the OWASP project republished that original material as its 1.0 release in 2015 and, after three years of preparation, released version 2.0 in early 2020. Compared with version 1.5, 2.0 added Implementation as a fifth business function with the new Defect Management practice, renamed Construction to Design, redesigned Verification, replaced Operational Enablement with Operational Management, arranged activities into two streams per practice, and introduced quality criteria with an updated scoring model; OWASP publishes a mapping from 1.5 to 2.0. Within the OWASP family, SAMM measures the program while OWASP ASVS sets verification requirements for an application and the OWASP Top 10 is an awareness document on the most critical web application risks, so organizations often pair the maturity model with those two documents.

Common Framework Mappings

OWASP SAMM is commonly mapped to the application security standards, secure development frameworks and control sets that its practices draw on, so one assessment can support several programs.

Mapped frameworks include:

BSIMM (Building Security In Maturity Model)

CIS Controls v8.1

ISO 27001:2022

ISO/IEC 27034

MITRE ATT&CK

NIST 800-218 SSDF

OWASP ASVS 4.0

OWASP Top 10 2021