OWASP SAMM: the Software Assurance Maturity Model, explained

OWASP SAMM (Software Assurance Maturity Model) is an open, vendor-neutral framework for measuring and improving an organization's software security practices over time, maintained as an OWASP project. OWASP's own homepage describes its purpose as "an effective and measurable way for any organization to analyze and improve their security posture." Unlike a pass/fail checklist, SAMM is structured as a maturity model: organizations score themselves against a defined set of practices at increasing levels of sophistication, track the score over time, and use the gaps to prioritize what to improve next. Version 1.0 was created in 2009 by Pravir Chandra; the model in current use is Version 2, with point releases continuing since — GitHub's release history for the SAMM core repository shows v2.1.0 (18 September 2023) and v2.2.0 (6 July 2024) as the two most recent tagged releases at the time of this guide.

Five business functions, fifteen security practices

OWASP SAMM's model page states it "defines five business functions and fifteen security practices." Each business function groups exactly three named practices:

Business function	Security practices
Governance	Strategy & Metrics · Policy & Compliance · Education & Guidance
Design	Threat Assessment · Security Requirements · Secure Architecture
Implementation	Secure Build · Secure Deployment · Defect Management
Verification	Architecture Assessment · Requirements-driven Testing · Security Testing
Operations	Incident Management · Environment Management · Operational Management

Read across, the five functions roughly trace a software lifecycle: Governance sets organizational direction before code is written, Design and Implementation cover building the software, Verification covers checking it, and Operations covers running it once shipped — closer in shape to NIST SSDF's PO/PS/PW/RV practice groups than the names suggest, though the two frameworks are not a 1:1 mapping; see NIST SSDF (SP 800-218): the four practice groups explained.

Two streams and three maturity levels per practice

Within each of the fifteen practices, OWASP SAMM's documentation splits activity into two streams — described as covering "different aspects of a practice" with "their own objectives, aligning and linking the activities in the practice over the different maturity levels" — and grades each stream across three maturity levels, where each level adds "successively more sophisticated objective[s] with specific activities, and more strict success metrics" than the one before.

As a concrete example, OWASP SAMM's own Strategy & Metrics practice page names its two streams "Create and Promote" and "Measure and Improve," and states the practice's three level objectives as:

Level	Objective, as stated by OWASP SAMM for Strategy & Metrics
1	Identify objectives and means of measuring effectiveness of the security program
2	Establish a unified strategic roadmap for software security within the organization
3	Align security efforts with the relevant organizational indicators and asset values

This stream-and-level structure repeats across all fifteen practices, each with its own pair of stream names and level objectives specific to that practice.

How this differs from NIST SSDF

SAMM and NIST SP 800-218 (SSDF) are both frequently cited as "the" software security framework to adopt, but they answer different questions. SSDF is a US-government-maintained set of named practices and tasks under four groups (PO, PS, PW, RV), with NIST's own documented mapping to Executive Order 14028's federal procurement clauses — see NIST SSDF (SP 800-218): the four practice groups explained. SAMM, by contrast, is an OWASP community project built explicitly as a self-assessment maturity model: its value is in the repeatable scoring across 2 streams × 3 levels per practice, letting an organization track its own trajectory release over release rather than checking boxes against a government procurement clause. Neither framework requires abandoning the other; a device or firmware team selling into US federal channels may use SSDF for the EO 14028 link while using SAMM internally to track year-over-year security program maturity.

A workable starting point

1. Self-assess against all fifteen practices once, at a shallow level, before deep-diving any single one. SAMM's value is in seeing the relative gaps across Governance, Design, Implementation, Verification and Operations, not in perfecting one practice while others sit at level 0.
2. Pick one stream per practice to move first, since each practice's two streams can mature independently — moving "Create and Promote" to level 2 in Strategy & Metrics does not require "Measure and Improve" to move at the same pace.
3. Treat level 3 as aspirational for most practices in year one. OWASP SAMM's own level definitions describe level 3 as organization-wide alignment with risk indicators and asset values — realistic only once the lower levels' habits are established.
4. Re-score on a fixed cadence (OWASP SAMM is designed to be reassessed, not scored once) so the maturity trend, not a single snapshot, drives what gets prioritized next.

SoftWSP's firmware and device security assessments map naturally onto SAMM's Verification and Operations functions — vulnerability testing and incident handling built on real component and firmware data: see device firmware security.

This guide summarises the public OWASP SAMM documentation at owaspsamm.org; it does not constitute legal or compliance advice.