OWASP SAMM: Measuring and Improving Secure Software Development

OWASP SAMM, the Software Assurance Maturity Model, helps an organisation answer two questions about its software security: how good are we today, and what should we improve next? It does not list application requirements (that is the role of the OWASP ASVS) or prescribe tools. Instead, it describes fifteen security practices across the software life cycle and the activities that make each one more mature, so teams can score themselves, set targets that match their risk, and improve in measured steps.

For software companies, SAMM is useful internally to plan security investment across teams, and externally to show customers and auditors a structured picture of secure development maturity. It maps well to the NIST SSDF and supports secure development expectations in ISO/IEC 27001 and the EU Cyber Resilience Act. This guide explains the model, how to run an assessment, how to build a roadmap, and the mistakes that make maturity programmes stall.

What is OWASP SAMM?

SAMM is an open framework maintained by the OWASP SAMM project. It is technology- and process-agnostic, applies to organisations of any size, and works with waterfall, agile and DevOps delivery. It has three layers:

• Business functions: five high-level areas of software development.
• Security practices: three per business function, fifteen in total.
• Streams and maturity levels: each practice is split into two streams of related activities, and each stream has activities at three increasing maturity levels.

Business function	Security practices
Governance	Strategy and Metrics; Policy and Compliance; Education and 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

The project provides an assessment toolbox (a spreadsheet and online tools) with questions for each stream and level, producing scores per practice that can be charted and compared over time.

History and why SAMM was created

SAMM was first published in 2009 as OpenSAMM, to give organisations an open alternative for measuring and improving software security programmes. It became an OWASP flagship project. Version 2, released in 2020, restructured the model with streams, added the Implementation business function to reflect build and deployment pipelines and DevOps, and updated activities and the assessment approach. The project continues to publish guidance, toolbox updates and benchmarking initiatives.

It exists because secure development is not a single tool or test. Organisations need a way to see which parts of the life cycle are weak, to avoid overinvesting in one area, and to show progress to leadership.

Who uses SAMM?

• Software product and SaaS companies building a secure development programme.
• Large enterprises with many development teams, comparing teams and setting common targets.
• IT service and outsourcing firms showing clients the maturity of their delivery process.
• Security leaders planning budgets and roadmaps.

It is voluntary and global.

The practices explained

Governance

Strategy and Metrics: a software security strategy aligned with business risk, and metrics to measure the programme. Policy and Compliance: internal security standards and mapping of external requirements, such as regulations and customer contracts, to development. Education and Guidance: training for developers and other roles, and accessible guidance such as secure coding standards.

Design

Threat Assessment: application risk profiles and threat modelling. Security Requirements: security requirements for software and for suppliers. Secure Architecture: architecture design principles and technology management, including approved components and patterns.

Implementation

Secure Build: a consistent, repeatable build process and management of software dependencies. Secure Deployment: automated, consistent deployment and secrets management. Defect Management: tracking security defects and using metrics and feedback to improve.

Verification

Architecture Assessment: verifying that architecture meets security requirements and mitigates threats. Requirements-driven Testing: testing controls and misuse and abuse cases derived from requirements. Security Testing: scalable baseline testing (automation) and deep manual testing.

Operations

Incident Management: detecting and responding to security incidents. Environment Management: configuration hardening and patching of the operating environment. Operational Management: data protection and system decommissioning and legacy management.

Maturity levels

Each stream has activities at three levels, broadly:

• Level 1: initial understanding and ad hoc provision of the practice.
• Level 2: increased efficiency and effectiveness of the practice.
• Level 3: full mastery of the practice at scale.

Scores are calculated from answers to assessment questions, which give credit for partial coverage, so a practice can score between levels. Level 3 everywhere is rarely the right goal; targets should reflect risk and resources.

How to run a SAMM assessment, step by step

1. Define scope: the whole organisation, a business unit, or a product team. Different teams can have different scores.
2. Identify stakeholders who know each area: engineering leads, architects, QA, DevOps, security, product.
3. Answer the assessment questions for each stream, with evidence rather than intentions.
4. Calculate scores using the toolbox and chart them by practice.
5. Set target scores for each practice based on risk, regulation and customer expectations.
6. Build a roadmap in phases (for example quarters), picking activities that close the most important gaps with the effort available.
7. Implement, assigning owners and integrating activities into normal delivery.
8. Reassess periodically, typically every six to twelve months, and update targets.

Running a useful assessment workshop

The quality of a SAMM assessment depends on how it is run. Practical tips from teams that use it:

• Assess per team or product when practices differ. An organisation-wide average can hide a team with no testing at all.
• Ask for evidence in the room: open the pipeline configuration, the threat model, the defect tracker. If nobody can show it, score it as not done.
• Include people outside security: developers, testers, DevOps and product owners know how work really happens.
• Keep it short: two or three focused sessions are better than a long questionnaire filled in by one person.
• Record notes per answer, so the next assessment can compare like with like.
• End with three priorities, not thirty. A roadmap that tries to fix everything stalls.

Metrics worth tracking

The Strategy and Metrics practice asks for measures that show whether the programme is working. Useful ones for software teams include:

• Time to remediate security defects by severity, against your policy targets.
• Share of repositories with required checks enabled (review, scanning, signing).
• Number of known vulnerable dependencies in production releases, and their age.
• Share of high-risk features with a threat model before development starts.
• Security defects found in production versus before release, as a sign of how well testing works.
• Training completion for developers and new joiners.

Report a small set consistently rather than many metrics occasionally, and connect them to the SAMM scores so leadership sees both maturity and outcomes.

Presenting SAMM results to customers

Customers increasingly ask suppliers how they develop software securely. A one-page SAMM summary works well: the scope and date of the assessment, current scores by business function, targets and the reasoning behind them, the main improvements delivered in the last year, and the next phase of the roadmap. Pair it with evidence customers already understand, such as an ISO/IEC 27001 certificate, a SOC 2 report or a recent penetration test summary.

An example roadmap for a growing SaaS company

Phase	Focus	Example activities
1	Foundations	Secure coding standard and training; dependency scanning; protected branches and mandatory review; incident response contacts and runbook
2	Design and testing	Lightweight threat modelling for high-risk features; security requirements in user stories (from the ASVS); automated SAST and DAST in CI
3	Pipeline and environment	Signed builds and SBOMs; secrets management; infrastructure hardening baselines; patch timelines
4	Measurement and depth	Security metrics dashboard; manual penetration tests for critical components; defect root cause analysis

Using SAMM with outsourced and offshore teams

When development is split between an in-house team and one or more partners, SAMM gives both sides a shared vocabulary. The buyer can set target maturity levels for practices it depends on, such as Secure Build, Security Testing and Defect Management, and ask the partner to self-assess against them with evidence. The partner can show how its standard delivery process meets those levels and where project-specific work is needed. Practices that span both organisations, such as Incident Management and Policy and Compliance, need explicit agreements: who triages a vulnerability report, who decides on a fix timeline, and who informs customers. Writing these into the statement of work avoids gaps that neither side owns.

Documentation you will need

• Assessment results with evidence references.
• Target scores and rationale.
• Roadmap with owners and dates.
• Policies and standards referenced by Governance practices.
• Records produced by activities: threat models, requirements, scan results, test reports, incident records.
• Reassessment history showing progress.

Assessment and certification

There is no SAMM certification. Assessments are self-run or performed by consultants. When sharing results with customers, explain the scope, date, method and evidence, and present targets and roadmap alongside current scores.

Timeline and cost considerations

A first assessment can be completed in a few workshops. The roadmap usually spans a year or more, with improvements delivered in phases. SAMM itself is free; costs come from staff time, training, tooling for scanning and pipelines, and external testing. Because targets are set by risk, SAMM helps avoid spending on activities that do not matter for your context.

Benefits and the risk of not measuring

SAMM shows where secure development is weak, helps prioritise investment, gives leadership a clear progress measure, and provides credible evidence for customers. Without a model, security improvements tend to follow the latest incident or tool purchase, leaving gaps in areas such as design, requirements or operations.

Common mistakes and challenges for IT companies

• Scoring intentions instead of evidence.
• Aiming for maximum maturity everywhere rather than risk-based targets.
• One-off assessments with no roadmap or reassessment.
• Security team owning everything; practices must be embedded in engineering.
• Ignoring Operations practices in product companies that also run the service.

Best practices, tools and technologies

• Use the SAMM toolbox or online assessment tools and store results in version control.
• Combine SAMM with the ASVS for requirements and the Top 10 for awareness.
• Appoint security champions in each team to own practices locally.
• Automate what can be automated: scanning, SBOMs, signing, policy checks.
• Report SAMM scores alongside delivery metrics so security is part of normal planning.

Our delivery process includes threat modelling, secure pipelines and security testing; see our custom software development approach.

SAMM vs BSIMM

BSIMM (Building Security In Maturity Model) is a descriptive model based on observed practices in participating organisations, useful for benchmarking against peers. SAMM is a prescriptive, open model designed to guide improvement and can be used without participating in a study. Many organisations use SAMM for planning and refer to BSIMM data for comparison.

How SAMM relates to other frameworks

Framework	Relationship
NIST SSDF	Defines secure development practices; SAMM measures maturity in implementing them, and the SSDF references SAMM.
OWASP ASVS	Application requirements that feed the Security Requirements and Requirements-driven Testing practices.
OWASP Top 10	Awareness material used in Education and Guidance.
CMMI	General process maturity model; SAMM focuses on security.
ISO/IEC 27001	Secure development controls (8.25 to 8.34) can be planned and evidenced with SAMM.
Cyber Resilience Act	Legal requirements for product security that a mature SAMM programme helps meet.

Real-world implementation examples

Organisations across finance, technology and government have published talks and case studies on using SAMM to structure their secure development programmes, and the SAMM project collects anonymised assessment data for benchmarking.

An illustrative case for an IT services firm: clients ask how secure its delivery process is. The firm runs SAMM across three delivery units, finds strong Implementation scores but weak Design and Governance, sets targets, introduces threat modelling and an ASVS-based requirements checklist, and trains security champions. A year later, reassessment shows clear improvement, and the scorecard becomes a standard slide in client proposals.

Next steps

1. Choose the scope and run a first SAMM assessment with evidence.
2. Set risk-based targets per practice.
3. Build a phased roadmap with owners.
4. Embed activities in delivery and automate them.
5. Reassess every six to twelve months and share a one-page summary with leadership and key customers.
6. Connect SAMM targets to the frameworks your customers ask about, such as the NIST SSDF or ISO/IEC 27001.

Frequently asked questions

What is OWASP SAMM?

An open maturity model for assessing and improving how an organisation develops secure software, with five business functions and fifteen security practices.

Is SAMM free?

Yes. The model and assessment tools are free and open.

Can a company be SAMM certified?

No. SAMM is used for self-assessment or independent assessment, not certification.

What are the five SAMM business functions?

Governance, Design, Implementation, Verification and Operations.

How many maturity levels does SAMM have?

Three per stream, with scores that can fall between levels to reflect partial coverage.

What is the difference between SAMM and ASVS?

SAMM measures the maturity of the development process. ASVS lists security requirements for applications.

How often should we reassess?

Typically every six to twelve months, or after significant organisational changes.

Is SAMM suitable for small teams?

Yes. Small teams can set modest targets and focus on the practices that matter most for their risk.

How does SAMM help with customers?

A scorecard with evidence and a roadmap gives customers a structured view of your secure development maturity and plans.

Who should run a SAMM assessment?

A security lead or experienced engineer who understands the model, with participation from each team being assessed. External assessors can add objectivity for a first baseline or for customer-facing results.

Does SAMM cover DevOps?

Yes. Version 2 added the Implementation function with Secure Build and Secure Deployment practices for modern pipelines.