OWASP SAMM: the Software Assurance Maturity Model, explained

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

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.

SAMM's model page also records where version 2 came from: the original 2009 model was reworked with "input from practitioners and the OWASP community gathered during summits in Europe and the US," and the SAMM FAQ dates the version 2 release to 31 January 2020.

Every practice has a stream A and a stream B. The names below are taken from the fifteen practice pages on owaspsamm.org (checked 12 November 2026), for example Secure Build:

Fifteen practices × two streams × three levels gives 90 activities, and the SAMM Assessment Guide confirms that a questionnaire-based assessment means going "through the list of 90 questions" — one question per activity.

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:

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. The FAQ gives one general reading that holds for all of them: level 1 is "an ad-hoc, best effort implementation," level 2 "a consistent, repeatable process that can be relied on," and level 3 aims "to maximize effectiveness through continuous improvement." It also states that a full 1 out of 1 on level 1 is "not strictly required" before working on level 2.

Synthetic example, not a customer case. A 60-person maker of home routers scores Secure Build across its three firmware product lines (SAMM's "applications" become product lines here):

The number alone says "below level 1." The stream split says something more useful: build automation is ahead, while dependency visibility lags. The cheapest next point is stream B level 1 — produce a firmware SBOM for the other two lines and check it for known CVEs — which would lift level 1 to 1.0 and the practice to 1.25 without touching the pipeline.

SAMM was written for software organizations in general, but several streams map directly onto firmware work and onto the evidence regulators and customers ask device makers for:

The Environment Management page adds at level 3: "Proactively obtain vulnerability and update information for components" — for a device maker that means watching advisories for components in firmware already sold, not only the next release. The Requirements-driven Testing page puts fuzzing at level 1 of stream B, which surprises teams that treat it as advanced work.

For the secure development lifecycle duties in IEC 62443-4-1 and the EU Cyber Resilience Act, SAMM is a measurement layer, not a substitute: see IEC 62443-4-1 secure development lifecycle. For pipeline-level maturity, OWASP's DevSecOps Maturity Model is narrower and more technical.

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.

• Answering "Yes" on intent. The toolbox instruction is to answer "No" unless every quality criterion is met; a dependency list without CVE lookup does not meet Secure Build stream B level 1.
• Reporting only the overall number. A 1.4 overall can hide a 0 in Patching and Updating, the stream closest to the security-update duties in the CRA checklist for device makers.
• Scoring "applications" inconsistently. If one interviewee counts firmware images and another counts cloud services, the 0.25 / 0.5 / 1 answers stop being comparable between rounds.
• Treating SAMM as certification. It is a self-assessment model; it gives no conformity statement under the CRA, EN 18031 or IEC 62443.
• Skipping level 1 because it looks basic. Fuzz testing, an SBOM and named incident-response roles all sit at level 1.

SoftWSP produces evidence for two SAMM streams, not a SAMM score. Its engine extracts an SBOM from a firmware image as CycloneDX 1.6 JSON, matches the components against NVD, CISA KEV, FIRST EPSS and CISA CSAF ICS advisories, and drafts a cited report that an engineer reviews — material for Secure Build stream B (Software Dependencies). Watchlist alerts on a CVE id or vendor-product support Environment Management stream B (Patching and Updating). Severity per finding can be checked in the free CVSS calculator, and the cluster's testing method is in the OWASP Firmware Security Testing Methodology guide. See device firmware security.

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