OWASP SAMM (Software Assurance Maturity Model) is a free, open framework for measuring and improving an organisation's software security practices. Version 2 is organised into five business functions, Governance, Design, Implementation, Verification and Operations, with three security practices in each. Every practice is scored on a maturity scale from 0 to 3, which makes it practical for setting targets and tracking progress over time.

How long does an OWASP SAMM assessment take?

A lightweight, evidence-based SAMM assessment can usually be completed in two to three weeks if the scope is limited to defined business units and a representative set of applications. Larger organisations with many development teams, or those wanting a separate score per team, will need longer. The time goes mainly into interviews, evidence review and a calibration session before results are shared.

What is a good OWASP SAMM maturity score?

There is no universal good score. The right target depends on the organisation's risk profile, how much software it builds itself, and the sensitivity of the data and transactions involved. A practical goal is to reach level 1 consistently across all fifteen practices first, then raise the practices where risk is concentrated to level 2. Few organisations need level 3 everywhere.

What is the difference between OWASP SAMM and BSIMM?

OWASP SAMM is a prescriptive, open model: it describes what good looks like and helps an organisation set its own targets. BSIMM (Building Security In Maturity Model) is descriptive: it reports which security activities are observed across participating organisations. SAMM is generally easier to self-assess and to turn into a roadmap, while BSIMM is mainly used for comparison with peers.

Can OWASP SAMM be used when software development is outsourced?

Yes. SAMM measures the organisation's own practices, and many of them still apply when vendors write the code: governance, security requirements, supplier oversight, verification and operations. The Security Requirements practice includes a Supplier Security stream specifically for this. Score only what the organisation can evidence, including contractual security requirements and the testing it performs on vendor deliveries.

Measuring application security maturity with OWASP SAMM: a practical starting point

Key takeaways

OWASP SAMM v2 measures application security maturity across five business functions, Governance, Design, Implementation, Verification and Operations, each split into three security practices.
A lightweight OWASP SAMM assessment can be completed in two to three weeks when it is tightly scoped and every score is backed by evidence rather than opinion.
Target maturity should reflect the organisation's risk profile; aiming for the highest SAMM level in every practice is rarely sensible or affordable.
SAMM gaps only become useful when they are turned into a sequenced 12 to 24 month roadmap with owners, budgets and measurable outcomes.
Mapping SAMM results to the NIST CSF 2.0 Govern function helps boards see application security as part of enterprise risk governance rather than a technical silo.

OWASP SAMM (Software Assurance Maturity Model) v2 is the most practical framework I know for measuring where an application security (AppSec) programme stands and deciding what to improve next. A lightweight assessment of two to three weeks, tightly scoped and scored against evidence, gives you a defensible baseline, a realistic target and a roadmap the board can follow. You do not need a large programme to start; you need honest answers.

What is OWASP SAMM v2?

SAMM is an open, vendor-neutral maturity model maintained by OWASP (the Open Worldwide Application Security Project). Version 2 organises application security into five business functions, each containing three security practices. Every practice has two streams of activity and three maturity levels, so progress can be measured in small, concrete steps rather than with one overall grade.

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

Why measure maturity instead of buying another tool?

Much of my delivery work is hands-on: SAST (static application security testing) and DAST (dynamic application security testing) with Veracode, vulnerability scanning with Tenable and Qualys, and protection for web applications and APIs (application programming interfaces) at the edge. These tools matter, but each one moves only a small part of the model. A SAST deployment improves Security Testing. If nobody triages the findings, Defect Management stays flat, and if developers never learn from the results, Education & Guidance does not move either.

SAMM makes that gap visible. It shows leadership the difference between owning a tool and operating a practice, and it stops the next budget conversation from defaulting to “which product next?”

How do you run a lightweight SAMM assessment in two to three weeks?

The aim is a credible baseline, not an audit. Keep the scope tight and the scoring evidence-led.

Week 1: scope, stakeholders and evidence

Agree which business units and which applications are in scope. A handful of representative applications, covering both in-house and vendor-built systems, is usually enough for a first pass. Identify interviewees across governance, architecture, development, QA (quality assurance), DevOps, IT operations, the SOC (security operations centre) and vendor management. Send an evidence request before the first interview: policies, standards, sample tickets, pipeline configurations, test reports, training records and incident reviews.

Week 2: interviews and draft scoring

Interview by business function rather than by team hierarchy, and keep each session focused. The official SAMM toolbox works well for recording answers. SAMM v2 attaches quality criteria to each question, and I apply them strictly: if the criteria are not met, the answer is not “yes”.

Week 3: calibration, target and roadmap

Hold a calibration session with the main stakeholders before any score is shared more widely. Disagreement at this stage is useful, because it usually reveals where a practice exists on paper only. Then agree targets, draft the roadmap and present the findings.

The checklist I work through:

Agree the scope in writing: business units, applications, and in-house versus outsourced development.
Name an internal sponsor who can unblock interviews and evidence requests.
Send the evidence request before the first interview.
Interview by business function, not by reporting line.
Score each stream only against evidence you have actually seen.
Record the evidence reference next to every score.
Hold a calibration session before sharing any numbers.
Set target scores per practice with the executive who owns the risk.

How do you score an AppSec maturity assessment honestly?

Inflated scores are a common failure in maturity work, and they are rarely deliberate. A few rules keep the results honest:

Policy is not practice. A secure coding standard that nobody can show being applied counts as a document, not an operating activity.
Coverage matters. SAMM’s answer scale distinguishes between an activity performed for some applications and one performed for most or all of them. Answer for the whole scope, not the best team.
Outsourcing is measured, not excused. The Security Requirements practice includes a Supplier Security stream, so contractual security requirements and vendor oversight are scored explicitly.
Report per practice, not as an average. A strong Security Testing score should never hide an empty Incident Management practice.
Avoid false precision. Decimal scores reflect the scoring method, not exactness. Present direction and bands to non-technical audiences.

How do you choose a target maturity?

Targets should be set per practice and driven by risk: internet-facing transactional systems, regulated data, how much software is built in-house, and how much depends on vendors. An organisation with in-house digital channel teams needs stronger Design and Implementation practices. One that mostly buys and configures software may put more weight on Supplier Security, Environment Management and Operations.

My working rule is to reach level 1 consistently across all fifteen practices before pushing for level 2 in the few where risk is concentrated. Level 3 everywhere rarely justifies its cost.

How do you turn SAMM gaps into a 12–24 month security roadmap?

Group the gaps into initiatives, and give each one an owner, a budget line, a measurable outcome and the SAMM stream it is expected to move. A typical shape looks like this:

First six months: foundations. An approved AppSec strategy, an application inventory, refreshed policies and standards, SAST and DAST on the highest-risk applications with a working triage process, and agreed remediation timelines.
Six to twelve months: build it in. Threat modelling for significant changes, security requirements in vendor contracts, role-based training for developers, and security checks in delivery pipelines.
Twelve to twenty-four months: measure and refine. Architecture assessments, metrics that feed back into strategy, stronger operational management, and a reassessment.

Reassess at least annually, using the same scope and method, so the trend is meaningful.

How do you stop the roadmap from stalling?

Roadmaps rarely fail because the analysis was wrong. They fail because nobody owns them once the assessment team leaves. A few habits help:

Use the existing planning cycle. Put each initiative into the normal budget and project portfolio rather than a separate security plan that competes for attention.
Start with a visible win. Fixing the triage process for findings you already have, for example, shows progress without new spending.
Review quarterly with the sponsor. Ask which streams moved, which stalled, and why.
Use contract renewals. Where vendors build or run key applications, add roadmap items such as security requirements and testing evidence to the next renewal rather than waiting for a new procurement.
Resist new bureaucracy. Embed AppSec activities in existing development and change processes instead of adding parallel approval steps that teams will route around.

How does SAMM connect to the NIST CSF 2.0 Govern function?

NIST CSF 2.0, the Cybersecurity Framework (CSF) published by the US National Institute of Standards and Technology (NIST) in 2024, added Govern as a sixth function alongside Identify, Protect, Detect, Respond and Recover. Govern is where boards and executive committees increasingly look, so it is a useful bridge. This is my working mapping, not an official crosswalk:

Strategy & Metrics supports Risk Management Strategy (GV.RM) and Oversight (GV.OV).
Policy & Compliance supports Policy (GV.PO).
The Supplier Security stream supports Cybersecurity Supply Chain Risk Management (GV.SC).
Clear ownership of AppSec activities supports Roles, Responsibilities, and Authorities (GV.RR).
Education & Guidance sits more naturally under Protect, in Awareness and Training (PR.AT).

For banks in Sri Lanka, and for regulated organisations in the Maldives and the Gulf Cooperation Council (GCC) states, regulators increasingly expect board-level oversight of technology risk. Expressing AppSec maturity in CSF 2.0 Govern terms makes it far easier to bring into that conversation.

How should you report SAMM results to the board?

Keep it to one page. Show current and target maturity by business function, name the three most important risks in plain language, list the milestones for the next two quarters, and state the decisions or budget you need. Leave the decimals in the appendix. Tie each risk to the organisation’s stated risk appetite, and use the same format at every review so the board can see the trend rather than relearn the model each time.

Where to start

Choose a scope you can assess properly in three weeks, gather the evidence first, and score only what you can see. If you want a quick first read before a formal assessment, try the free AppSec Maturity Scorecard on this site. It is not a substitute for an evidence-based SAMM assessment, but it will show you which business functions deserve a closer look.

Want a second opinion on your own environment? Book an assessment call or talk to the Innov8 AppSec team about implementation.