OWASP SAMM (Software Assurance Maturity Model) is an open framework for measuring how mature an organization's software security program is, across five business functions and 15 security practices, each scored on three levels. It grades the organization, not a single application.
What makes that distinction matter: in Fluid Attacks' 2026 benchmark, the best-performing scanner on the market detected 22.7% of the vulnerabilities in the target applications, while pentesters identified 89.6%. Two companies can own the same scanner and sit at opposite ends of the maturity scale, because the score depends on how consistently the work gets done, not on what was purchased.
This page covers what SAMM measures, how its maturity levels work, how it differs from ASVS and the OWASP Top 10, and what moving up a level takes.
What is OWASP SAMM?
SAMM sorts software security into five business functions — Governance, Design, Implementation, Verification and Operations — and splits each one into three security practices, for 15 in total. Every practice is scored on its own, so the output is not a single grade but a profile: which parts of the program are solid, and which are improvised.
That structure is what makes SAMM a maturity model rather than a checklist. It is open, vendor-neutral, and prescriptive about what to measure while staying deliberately silent about which tools to buy. Fluid Attacks maps its own security requirements to OWASP SAMM domains in a public database, so a team can trace a maturity goal down to the specific code-level requirement that satisfies it.
What is OWASP?
The Open Worldwide Application Security Project is a nonprofit foundation that publishes free, community-built resources for software security. Its best-known projects are the OWASP Top Ten, a ranking of the most critical web application risks, and the OWASP ASVS, a catalog of technical verification requirements.
SAMM sits at a different altitude than both. The Top Ten tells you what commonly goes wrong. ASVS tells you what a given application must satisfy. SAMM tells you how good your organization is at making either of those happen, consistently, over time.
Why is OWASP SAMM important?
Because application security has been getting harder faster than most programs have been maturing. In Fluid Attacks' State of Attacks 2026, which covers systems assessed between January 1 and December 31, 2025, 70% of assessed systems had at least one high- or critical-severity vulnerability, up from 53.3% in 2024.
Remediation improved in the same period, to a 62.2% rate, 21.2 percentage points above 2024. Both things being true at once is the argument for a maturity model: teams that measure their program improve it, and teams that rely on isolated efforts get outpaced by their own attack surface.
The other reason is that buying tools does not raise maturity by itself. In the same report, manual testing found 87% of critical-severity vulnerabilities while automated tools found 13%, and vulnerabilities found by tools averaged 15.5 CVSSF units against 93.2 for those found by pentesters. A program that scores well on tooling and poorly on verification practice will keep missing the findings that matter most.
SAMM also pairs naturally with prescriptive guidance. NIST SP 800-218, the Secure Software Development Framework published in 2022, lists the practices a team should perform; SAMM measures how consistently the team actually performs them. One is the checklist, the other is the scorecard.
OWASP SAMM v2: business functions and security practices
SAMM v2 replaced the three domains of v1.0 with the five business functions above, and restated each of the 15 practices around activities a team can evidence rather than intentions it can declare. The version matters when you compare mappings: material built on v1.0 still applies, but its labels are different.
The framework ships with a maturity model describing each practice, a SAMM Toolbox for running the assessment, and a SAMM Benchmark for comparing results against other organizations.
Business function | What it covers | Security practices |
Governance | How security is steered and measured | Strategy & Metrics · Policy & Compliance · Education & Guidance |
Design | How security enters the product before code exists | Threat Assessment · Security Requirements · Security Architecture |
Implementation | How software gets built and defects get managed | Secure Build · Secure Deployment · Defect Management |
Verification | How the result gets checked | Architecture Assessment · Requirements-driven Testing · Security Testing |
Operations | How the running system stays defensible | Incident Management · Environment Management · Operational Management |
SAMM, ASVS and the OWASP Top 10 are not alternatives
Teams often ask which of the three to adopt. They answer different questions and most mature programs use all three.
OWASP SAMM | OWASP ASVS | OWASP Top 10 | |
Question it answers | How mature is our security program? | Does this application meet its security requirements? | What goes wrong most often? |
Unit of measure | Maturity level per practice (1–3) | Verification requirement, pass or fail | Risk category, ranked |
Scope | The organization | One application | The industry |
Typical use | Plan a roadmap, justify investment | Define a contract or a test plan | Prioritize training and awareness |
Fluid Attacks mapping |
The Top 10 is also a moving target worth tracking. Its 2025 edition analyzed 589 CWEs, up from roughly 400 in 2021, and put Software Supply Chain Failures in third place — a category that barely registered two editions earlier.
OWASP SAMM maturity levels
Each of the 15 security practices is scored on three maturity levels, and an implicit level 0 means the practice is absent. The levels describe consistency, not effort.
Level | What it looks like | How you can tell |
1 | Ad hoc. The practice happens, driven by individuals | Two teams do it differently and nobody notices |
2 | Defined and repeatable. The practice is documented and applied across teams | A new team can follow it without asking anyone |
3 | Measured and optimized. The practice is instrumented and improved from its own data | You can show the trend, not just the policy |
The jump from 2 to 3 is where most programs stall, because it requires data the organization has not been collecting. That is the gap this article's remaining sections address.
OWASP SAMM at Fluid Attacks
Fluid Attacks assesses only the systems a client explicitly authorizes, within an agreed scope, and reports every finding to the client's own team through its platform. Nothing described here is performed on third-party systems.
SAMM is a framework Fluid Attacks maps to, not a product it sells. The practical value is in the instrumentation: the controls SAMM asks you to demonstrate are the ones a security testing program produces evidence for.
The published mapping covers v1.0 domains
Fluid Attacks' public SAMM mapping is built on SAMM v1.0 and organizes 23 security requirements across three domains: Security Architecture (6), Security Testing (9) and Operational Management (8). In v2, those domains were regrouped — Security Architecture into Design, Security Testing into Verification, Operational Management into Operations — so the requirements still apply; only the labels changed. Each entry opens a full requirement page, such as the one for verifying third-party components.
What each business function looks like in practice
Business function | How Fluid Attacks instruments it | Evidence |
Governance | Risk exposure metrics in the platform; a public requirements database; its own house certified | 23 requirements mapped to SAMM domains; ISO/IEC 27001 and 27701, SOC 2 and SOC 3, PCI DSS validation |
Design | Security requirements with acceptance criteria per entry | A public page per requirement, each with its rationale and references |
Implementation | SAST, SCA and CSPM in the pipeline, plus a CI Gate that breaks the build. For triage: VLAI severity, EPSS, exploitation Signals and a Reachability Capability indicator | Systems using the CI Gate reached a 72.2% remediation rate against 58% without it |
Verification | DAST and MAST alongside manual penetration testing and secure code review | Manual testing found 87% of critical-severity vulnerabilities; tools found 13% |
Operations | Verified reattacks and vulnerability management in one place | 62.2% overall remediation rate at the end of 2025; 63.8% on critical severity |
On the Implementation row, the triage signals are documented in the platform and database changelog: every vulnerability in the database now displays a VLAI severity rating that complements CVSS and EPSS, real-world exploitation activity is labeled as Signals, and the vulnerability detail page includes a Reachability Capability section with three states — supported, not supported and impossible.
The original model was written by Pravir Chandra in 2009. Image source: OWASP SAMM.
Point-in-time versus continuous verification
The Security Testing practice is where the maturity levels bite hardest, because the difference between level 1 and level 3 is not which tool you run but how often you run it and how much of the result is human.
Measure | Point-in-time, tool-driven | Continuous, tool plus human |
Share of critical-severity vulnerabilities found | 13% (automated tools) | 87% (manual testing) |
Average CVSSF per finding | 15.5 | 93.2 |
Detection rate in a 36-tool benchmark | 22.7% (best-performing scanner) | 89.6% (pentesters) |
Remediation rate | 58% without a CI Gate | 72.2% with a CI Gate |
Median time to remediate | 32 days | 21 days |
Detection figures come from the State of Attacks 2026; the benchmark row comes from a benchmark of 36 third-party tools published in February 2026, in which the best-performing scanner detected 22.7% of vulnerabilities while pentesters identified 89.6%.
A perfect score on a test suite is not a maturity level
There is a useful contradiction in those numbers. In 2021, Fluid Attacks' scanner reached a maximum OWASP Benchmark accuracy score of 100, with 100% true positives and zero false positives. Five years later, in a benchmark run against 1,076 real vulnerabilities, the best scanner on the market — any scanner — found 22.7% of them.
Both results are correct. The OWASP Benchmark is a synthetic Java test suite with known answers, and scoring 100 on it proves a scanner does what scanners do, precisely.
▶️ Watch: The OWASP Benchmark result, explained by the team that ran it.
Real applications contain business logic flaws, broken authorization and chained conditions that no test suite encodes and no scanner is built to reason about. This is exactly why SAMM scores the Verification practice on how the organization tests, not on which tools it owns: a team can buy the most accurate scanner in the world and still sit at level 1.
The platform benchmarks an organization's remediation rate against the best, average and worst performers in the cohort — the operational equivalent of the SAMM Benchmark, applied to findings rather than self-assessment answers.
Governance is the practice that decides the rest
Strategy & Metrics is listed first in SAMM for a reason. Fluid Attacks' guidance on implementing DevSecOps makes governance the precondition rather than the paperwork: a company has to monitor its procedures, measure its performance, name its obstacles and failures, and improve from the feedback.
The metrics a team accumulates as its DevSecOps practice matures are what make governance decisions defensible instead of intuitive — which is the same argument SAMM makes when it puts Strategy & Metrics ahead of every technical practice.
How to achieve a high maturity level
Run an assessment, pick the two or three practices with the widest gap, and instrument them so the next assessment is measured rather than estimated. SAMM's own Toolbox gives you the questionnaire; the work is everything after it.
Three steps carry most of the weight.
Assess honestly. A self-assessment that scores every practice at level 2 is a scoring exercise, not a diagnosis. Where you have no data, the answer is level 1.
Close the Verification gap first. It is the practice with the most direct effect on the others and the easiest to instrument, through security testing that combines vulnerability scanning with penetration testing as a service. Fluid Attacks' analysis of continuous penetration testing makes the limitation plain: a point-in-time assessment gives you a baseline worth comparing against the next one, but says nothing about whether the system withstood the attacks aimed at it in between. A maturity level that depends on an annual snapshot is a maturity level you cannot evidence for eleven months of the year.
Make level 3 measurable. Level 3 means improving the practice from its own data, which requires a trend line long enough to read. Compliance obligations are usually what funds this step, and they map onto the same evidence — see compliance for the standards a testing program can produce evidence against.
Closed, accepted and open risk exposure by year for one organization, from 98.54% open in 2019 to 82.54% closed in 2026. A trend like this is what level 3 evidence looks like: the practice improving from its own data.
Conclusions
OWASP SAMM is useful because it separates two questions organizations tend to merge: whether an application is secure, and whether the organization is good at making applications secure. The second one is what determines the first, next quarter and the one after.
The framework will not tell you which scanner to buy, and that is a feature. What it will do is expose which of the 15 practices you cannot produce evidence for, which is almost always the honest starting point. In 2025 the share of systems carrying at least one high- or critical-severity vulnerability rose to 70%, so the gap between a documented practice and a measured one is not an academic distinction.
Frequently asked questions
What is the difference between OWASP SAMM and OWASP ASVS?
SAMM measures how mature an organization's security practices are; ASVS lists the technical verification requirements a specific application must meet. SAMM scores the program, ASVS tests the product. A team can score level 3 on Verification precisely because it runs ASVS-driven testing consistently.
How many maturity levels does OWASP SAMM have?
Three per security practice, plus an implicit level 0 when the practice does not exist. Level 1 is ad hoc, level 2 is defined and repeatable, level 3 is measured and optimized. Because all 15 practices are scored separately, an organization ends up with a maturity profile rather than one number.
How long does it take to raise your SAMM maturity level?
It depends on your starting point and on whether your pipeline already enforces security controls. Fluid Attacks' State of Attacks 2026 found that systems using a CI Gate reached a 72.2% remediation rate against 58% without one, and cut the median time to remediate from 32 days to 21 — the kind of instrumented improvement a level 3 score requires evidence of.
Is OWASP SAMM only for large enterprises?
No. It applies to any organization that builds its own software. The assessment effort scales with team size, and small teams often move faster between levels because fewer processes need to change. What does not scale down is the need for evidence.
Does Fluid Attacks use OWASP SAMM?
Yes. Fluid Attacks maps its security requirements to SAMM domains in a public database. The mapping covers 23 requirements and each one opens a full requirement page, so a maturity goal can be traced to the specific control that satisfies it.
Turn the score into evidence
Continuous testing gives your Verification practice the data a level 3 score has to be backed by. Start free trial · Contact us
