OWASP SAMM – Tutorial (about 60 minutes)

OWASP SAMM, the Software Assurance Maturity Model, is a free and open model that helps an organisation measure how well it builds, runs and governs secure software, and then plan realistic improvements step by step. Security leads, engineering managers, architects, DevOps teams, product owners and auditors use it to get an honest picture of their software security practices across the whole lifecycle, from strategy and design to deployment and operations. After this tutorial you will be able to explain how the model is organised, run a small self-assessment, calculate and read SAMM scores, turn the results into a phased roadmap, and explain how SAMM sits next to frameworks such as BSIMM, the NIST SSDF, OWASP ASVS and ISO/IEC 27001.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current model is OWASP SAMM version 2, published by the SAMM project of the OWASP Foundation (the Open Worldwide Application Security Project, a non-profit). SAMM 2.0 was released on 31 January 2020, after the original 2009 model (OpenSAMM 1.0) and version 1.5 of 2017. Since then the model has been maintained as open data in the project's "core" repository: release 2.1.0 (September 2024) added assessment guidance, agile guidance, framework mappings, a PDF edition and benchmark support, and release 2.2.0 (July 2026) is a maintenance release that improves wording, grammar and terminology (including the wording of some answer options) without changing the structure of five business functions, 15 security practices, 30 streams and 90 activities. No version 3 has been announced. SAMM is an OWASP Flagship project, licensed under Creative Commons Attribution-ShareAlike 4.0. There is no official SAMM certification for organisations or people. Verified 2026-10-29 against owaspsamm.org and the owaspsamm/core repository on GitHub.

Who this is for: software engineers and engineering managers, security champions, application security (AppSec) staff, architects, QA and test leads, DevOps and platform engineers, product owners, and governance, risk and compliance people who have been asked to "do a SAMM assessment" or to build a software security programme and want a structured place to start.

Prerequisites: none. It helps to know roughly how software is planned, built, tested and released in your organisation, but every security term is explained when it first appears.

By the end of this tutorial:

• You will be able to explain why SAMM exists, who maintains it, what "maturity" means in this model and why SAMM is a self-improvement tool rather than a certification scheme.
• You will be able to describe the structure of the model: five business functions, fifteen security practices, two streams per practice, three maturity levels and the activities with their quality criteria.
• You will be able to run a lightweight self-assessment for a defined scope, choose the right answers using the quality criteria, and record evidence and observations.
• You will be able to calculate stream, practice and overall scores and interpret them, including "percent to target" and "progress to date".
• You will be able to follow the six-step improvement cycle (prepare, assess, set the target, define the plan, implement, roll out) and build a phased roadmap.
• You will be able to compare SAMM with BSIMM, the NIST Secure Software Development Framework, OWASP ASVS and ISO/IEC 27001, and choose the right tool for a given question.

Lesson 1 – Origins, purpose and scope

The problem SAMM solves

Almost every organisation now writes or assembles software, and almost every serious breach story includes a software weakness somewhere: an injectable query, a leaked secret, a forgotten server, an unpatched library. Most organisations already do some security work. A team runs a code scanner, someone paid for a penetration test last year, there is a policy document on the intranet. The difficulty is that these efforts are usually scattered. Nobody can say, in a way that management and engineers both accept, how good the organisation really is at software security, which gaps matter most, and what to do next with a limited budget.

SAMM was created to answer three practical questions. Where are we today? Where do we want to be, given our risks? What is a sensible path from here to there? It does this by describing, in plain language, the security activities that a software-producing organisation can perform, organised so that each area can be measured on a simple scale and improved in small steps.

A short history

The model began in 2009 as OpenSAMM, written by Pravir Chandra. It was donated to OWASP, the global open-source community best known for the OWASP Top 10 awareness list, and became the OWASP SAMM project. Version 1.5, released in 2017, refined the scoring so that an organisation got credit for all of the related work it was doing in a practice. Version 2.0, released on 31 January 2020 after about three years of community work, was a major redesign: it added the Implementation business function, introduced two "streams" inside every practice, added quality criteria to every activity and moved the whole model into machine-readable data files so that tools can be generated from it. Later releases (2.1 in 2024, 2.2 in 2026) improved guidance, tooling and wording rather than the structure.

Another well-known model, BSIMM, grew out of the same early work around 2008 and 2009. The two then went separate ways. BSIMM became a descriptive study of what real companies actually do; SAMM stayed a prescriptive, open model of what an organisation could do. Lesson 7 returns to this difference.

Design principles

The SAMM project describes the model as measurable, actionable and versatile. Measurable means there are defined maturity levels in every practice, so you can score yourself. Actionable means each level describes concrete activities, so a low score immediately suggests the next step. Versatile means the model is independent of technology, development process and organisation size: it works for a ten-person start-up building one mobile app and for a bank with hundreds of teams, for waterfall projects and for teams that deploy many times a day.

Two further ideas run through the whole model. First, SAMM is risk-driven. It does not expect every organisation to reach the highest level everywhere. A company that processes card payments will set higher targets than a company that publishes a recipe blog, and both are using SAMM correctly. Second, SAMM is meant to be used repeatedly. One assessment gives a snapshot; the value comes from assessing, improving and re-assessing over months and years.

What is in scope and what is not

SAMM covers the organisational side of software security: governance, design, implementation, verification and operations of software. It is about practices and capabilities, not about individual vulnerabilities. It does not tell you whether a specific application is free of SQL injection; for that you need testing against a requirements standard such as OWASP ASVS. It is also not a full information security management system; it focuses on software, while standards such as ISO/IEC 27001 cover the wider organisation. Finally, SAMM is not a law or a contractual standard. Nobody is required to follow it, which is exactly why it can be honest and flexible.

Lesson 2 – Key concepts and vocabulary

SAMM uses a small, precise vocabulary. Learn these terms first; the rest of the tutorial uses them constantly.

• Software assurance – the level of confidence that software is free from exploitable weaknesses and behaves as intended, achieved through deliberate activities across its lifecycle rather than by luck.
• Maturity model – a structured description of capability that grows in stages, so an organisation can place itself on a scale and see what the next stage looks like.
• Business function – one of the five top-level groups of software activities in SAMM: Governance, Design, Implementation, Verification and Operations. Every software-producing organisation performs all five to some degree.
• Security practice – one of the fifteen areas of security work, three per business function, for example Threat Assessment or Secure Build. Practices are what you score and improve.
• Stream – one of the two sub-areas inside each practice, labelled A and B. Each stream covers a different aspect of the practice, for example the Secure Build practice has a stream about the build process and a stream about software dependencies.
• Maturity level – one of three steps inside each stream. Level 1 is an ad hoc, best-effort start; level 2 is a consistent and repeatable process; level 3 is an optimised process that improves itself through feedback.
• Activity – the concrete piece of work described for one stream at one maturity level. With 15 practices, 2 streams and 3 levels, the model contains 90 activities.
• Assessment question – the question attached to each activity that an assessor asks to find out whether, and how widely, the activity is performed.
• Quality criteria – a short list of conditions attached to each question. They describe what "doing the activity properly" means, so that two assessors reach the same answer.
• Answer options – the four possible answers to each question, worth 0, 0.25, 0.5 and 1 point. The wording varies by question (for example "for some applications" or "ad hoc / regularly / continuously"), but the four steps are always the same.
• Scope – the part of the organisation being assessed: a single team or product, a business unit, or the whole enterprise.
• Target – the maturity you decide you need, practice by practice, based on risk, obligations and resources.
• Roadmap – a plan, split into phases, that moves the organisation from its current scores toward the target.
• SAMM Toolbox – the official spreadsheet (Excel or Google Sheets) with the interview questions, automatic scorecards and a roadmap worksheet.
• Benchmark – the SAMM initiative that collects anonymised assessment results from many organisations so that users can compare themselves with peers.
• Security champion – a member of a development team who takes a special interest in security, acts as the team's contact point and helps spread practices. Champions appear explicitly in the Education and Guidance practice.

Prescriptive versus descriptive

You will often read that SAMM is "prescriptive". This means the model tells you which activities make up good practice and in which order they usually make sense. A descriptive model, by contrast, observes what organisations actually do and reports how common each activity is. Prescriptive does not mean rigid: you still choose your own targets and may skip activities that do not apply to you.

Coverage and quality

SAMM 2 measures two things at once. Coverage asks how widely an activity is performed: for one application, for half of them, for nearly all of them. Quality asks whether it is performed well enough to count, which is what the quality criteria check. A team that runs a scanner on every repository but ignores the results scores poorly on quality even though coverage is high. This double view is one of the main improvements of version 2 over earlier editions.

Lesson 3 – Structure of the model

The SAMM structure is a clean hierarchy. Once you see it, the 90 activities stop looking overwhelming, because each one has an exact address.

The five business functions

Governance covers how the organisation steers its software security effort: strategy, policies, compliance obligations, training and culture. Design covers what happens before code is written: understanding risk and threats, defining security requirements (including for suppliers) and choosing secure architectures and technologies. Implementation covers how software is built and delivered: the build pipeline, dependencies, deployment, secrets and the handling of security defects. Verification covers how you check that the software is secure: architecture reviews, testing derived from requirements, and broader security testing. Operations covers life after release: incident detection and response, environment hardening and patching, and operational topics such as data protection and decommissioning.

Practices and streams

The table lists all fifteen practices with their two streams, using the names in the current model data. Streams are deliberately different in character: often one stream is about doing the core work and the other about managing, measuring or extending it.

Business function	Security practice	Stream A	Stream B
Governance	Strategy and Metrics	Create and Promote	Measure and Improve
Governance	Policy and Compliance	Policy and Standards	Compliance Management
Governance	Education and Guidance	Training and Awareness	Organization and Culture
Design	Threat Assessment	Application Risk Profile	Threat Modeling
Design	Security Requirements	Software Requirements	Supplier Security
Design	Secure Architecture	Architecture Design	Technology Management
Implementation	Secure Build	Build Process	Software Dependencies
Implementation	Secure Deployment	Deployment Process	Secret Management
Implementation	Defect Management	Defect Tracking	Metrics and Feedback
Verification	Architecture Assessment	Architecture Validation	Architecture Mitigation
Verification	Requirements-driven Testing	Control Verification	Misuse/Abuse Testing
Verification	Security Testing	Scalable Baseline	Deep Understanding
Operations	Incident Management	Incident Detection	Incident Response
Operations	Environment Management	Configuration Hardening	Patching and Updating
Operations	Operational Management	Data Protection	System Decommissioning / Legacy Management

The model also gives every element a short identifier, which is handy in spreadsheets and tickets. The pattern is function letter, practice initials, stream letter and level number. For example D-TA-B-1 on the SAMM website means Design, Threat Assessment, stream B (Threat Modeling), level 1. In the model data files the same activity is stored as D-TA-1-B.

The three maturity levels

Inside each stream the three levels form a ladder. The lower levels are easier and need less formal process; the higher levels need more organisation, tooling and measurement. A useful way to remember the ladder is: level 1 means "we do it, at least sometimes, on a best-effort basis"; level 2 means "we do it the same way every time, and people can rely on it"; level 3 means "we measure how well it works and keep improving it".

Two streams in practice: an example

Take the Threat Assessment practice. Stream A, Application Risk Profile, is about knowing which applications are risky. At level 1 you perform a simple risk assessment per application so you can classify them; at level 2 you keep an inventory of these risk profiles across the portfolio; at level 3 you review the profiles periodically so that the classification stays accurate when applications change. Stream B, Threat Modeling, is about finding design flaws. At level 1 teams run lightweight, best-effort threat modeling for high-risk applications, using simple checklists such as STRIDE (a mnemonic for six threat categories: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege). At level 2 threat modeling is standardised and scaled with an agreed method and training. At level 3 the organisation reviews and optimises its threat modeling approach itself.

Notice how the two streams support each other. The risk profile from stream A tells you where to spend threat modeling effort in stream B. Many practices work like this, and many activities depend on earlier ones, both inside a stream and across practices: you cannot measure adherence to policies and standards (Policy and Compliance, level 3) before you have written them (level 1), and test cases derived from requirements (Requirements-driven Testing) need security requirements to exist first.

Questions, criteria and answers

Every activity has a question in the form "Do you …?". Under the question sits a short list of quality criteria. In the Threat Modeling level 1 question, for instance, the criteria check that threat modeling is done for high-risk applications, that a simple checklist is used and that the outcome is kept for later use. The official guidance is strict: if the quality criteria are not fully met, the answer is "No". Only when the criteria are met do you choose among the three "Yes" answers, which express how widely or how often the activity happens.

The four answer steps carry fixed values: 0 for "No", 0.25 for the smallest "Yes", 0.5 for the middle one and 1 for the fullest one. Depending on the question, the "Yes" answers talk about the share of applications, components, teams, incidents or data covered, or about frequency (ad hoc, regularly, continuously), or about how far a rollout has gone (started, part of the organisation, the whole organisation). This is how SAMM captures coverage as well as quality.

Lesson 4 – How it works in practice

SAMM is used in a repeating improvement cycle. The project's getting-started guide describes six steps. Steps one to four are planning and can be done quickly, in days rather than months; steps five and six are the real change work and typically run over several phases.

Step 1 – Prepare

First define the scope. The guidance lists three common options: a single team, product or system; a business unit with its own risk or regulatory profile; or the whole organisation. A whole-organisation scope gives the broadest picture but has a steep learning curve, so first-timers are advised to start small. A useful test is consistency: everyone inside the scope should work in broadly the same way, with shared procedures and management. If teams in your scope build, test and deploy in completely different ways, the scope is too wide and a single score would hide the truth.

Next identify stakeholders: an executive sponsor, the security team, developers, architects, business owners, testers and managers. Then build awareness, explaining what SAMM is, why you are doing it and that the goal is improvement, not blame. Write down the goals of the exercise (for example, a baseline for a three-year programme, or evidence for a customer's supplier questionnaire), the scope, assumptions and the people involved. This documentation is what makes your next assessment comparable with this one.

Step 2 – Assess

Now determine the current maturity of the scope across all fifteen practices. You can answer the questionnaire yourself if you know the organisation well, or interview the people who do the work. Lesson 5 explains assessment methods and scoring in detail. The output is a scorecard: a number between 0 and 3 for every stream, practice and business function, plus notes explaining each answer.

Step 3 – Set the target

For each practice, decide which activities you want in place by the end of the programme. The target should follow your risk profile and obligations, not a wish to look impressive. Two pieces of advice from the guide are worth remembering: targets usually contain many more lower-level activities than higher-level ones, and the set of chosen activities must make sense as a whole, respecting dependencies between them. Estimate what the target will cost in people, tools and time, and get the sponsor's agreement. The Toolbox has a roadmap worksheet where you enter target answers next to current ones, and the SAMM benchmark can help you judge whether a target is unusual for your sector.

Step 4 – Define the plan

Split the journey into phases. The guide suggests a typical roadmap of four to six phases, each lasting roughly three to twelve months. Put quick wins and awareness or training early, because they create momentum and make later activities easier. Align phases with real release cycles and key projects, spread effort evenly so that no phase is overloaded, and respect dependencies (for example, define security requirements before you plan requirements-driven testing). Each roadmap item should have an owner, a budget line and an expected effect on the score.

Step 5 – Implement

Carry out the roadmap activities. This is ordinary change management: write the standard, configure the pipeline, train the people, adapt the templates. SAMM's activity descriptions help here because each one explains the intended benefit and gives practical hints. The project also publishes stream guidance from the core team and community, a guide for agile teams, and a guide for AI-assisted development that explains how AI coding assistants affect each stream without changing the core model.

Step 6 – Roll out

An improvement that exists only on paper does not raise maturity. Rolling out means making improvements visible and usable across the scope: training, internal communication, management updates, and the security champion network carrying new habits into teams. It also means measuring adoption and effectiveness, for example how many teams actually use the new threat modeling template or how quickly critical defects are now fixed. Then the cycle returns to step 2: you re-assess, compare with the baseline and adjust the plan.

Roles and artefacts

A SAMM programme usually has an executive sponsor who owns the budget and priorities, a programme lead (often the AppSec manager) who runs the cycle, assessors who collect answers, and practice owners who drive improvements in each area. Development teams, architects, testers and operations staff are both the subjects of the assessment and the people who implement the roadmap. SAMM's skills framework maps each stream to the roles that lead and support it, which helps decide who should answer which questions and who should own which roadmap items.

Typical artefacts are a scope statement, the completed Toolbox with answers and observations per stream, a scorecard chart for management, a target and roadmap sheet, and a short report explaining the main findings and decisions.

SAMM in agile and DevOps teams

SAMM does not assume any particular development method. The agile guidance stresses that security should be owned by everyone, including the product owner, with security specialists acting as advisers rather than gatekeepers. Security topics should come up regularly in backlog refinement and retrospectives. Requirements that apply to the whole system can be referenced from the team's Definition of Done, while story-specific security requirements are chosen during story writing or refinement and added to acceptance criteria. Threat models are updated incrementally as the system changes, security tests are automated as far as possible, and the remaining manual testing and code review focus on what has changed instead of re-testing everything just before a release.

Lesson 5 – Assessment, scoring and the question of certification

Self-assessment and expert assessment

SAMM assessments come in two broad flavours. A self-assessment is done by people inside the team or organisation. It is quick and cheap, needs no outside help, and is a good way for the team to learn the model. Its weakness is consistency and depth: insiders may not know what good looks like for every activity, and different teams read the same question differently. An expert assessment is run by an independent internal assessor or an external SAMM practitioner. It takes more time, but it is usually more accurate and more useful for planning, because the assessor knows what good looks like and asks follow-up questions. The guidance recommends mixing both approaches, for example an expert-led baseline followed by lighter self-assessed updates.

The project also distinguishes a lightweight assessment, based on answers and discussion, from a detailed assessment, in which every answer is backed by evidence such as configuration files, pipeline definitions, tickets, documents or logs. A detailed assessment is slower and is worth the effort mainly when you need high confidence in the scores, for instance before reporting them to a board or a major customer.

Questionnaire or interview?

Sending the full questionnaire of about 90 questions to people by email is tempting but often fails. Respondents get tired, skip criteria and interpret questions differently, so the scores across teams are not comparable. Interviews and workshops work better: the interviewer can explain each question and its criteria, ask for examples, double-check answers with several people and notice hesitation. Good practice from the assessment guide includes using the same questions and interviewer across teams, asking the same question to more than one person, making sure interviewees understand each activity, considering anonymous input where honesty might suffer, and not reading questions too literally. Questionnaires remain useful for updating a few scores later, once stakeholders understand the model.

Record observations next to each stream: what people said, what evidence you saw, and why you chose an answer. Decide in advance how you will treat partial credit and activities that do not apply, and document every judgement call. These notes turn a number into something people can act on.

How the scores are calculated

The Toolbox calculates scores automatically, but you should understand the arithmetic so that you can explain and challenge results.

Each activity gets the value of its answer. A stream's score is the sum of its three activity scores, so it ranges from 0 to 3. A practice score is the average of its two stream scores, again 0 to 3. Business function scores and the overall score are averages of the level below, so every number in a SAMM scorecard sits on the same 0 to 3 scale. This is the convention of the SAMM Toolbox and of the project's 2025 article on scoring; one older getting-started page describes adding practice scores together for an overall total instead, so always state which convention a reported number uses. For example, if the Application Risk Profile stream has answers 1, 0.5 and 0 for levels 1, 2 and 3, its score is 1.5. If the Threat Modeling stream has 0.25, 0 and 0, its score is 0.25. The Threat Assessment practice score is then the average of 1.5 and 0.25, which is 0.875.

Because scores are sums of partial answers, a score such as 1.5 does not mean "level 1 and a half" in a strict sense. It means the organisation earns that many points across the three levels. A team can earn some level 2 points before level 1 is complete: the SAMM FAQ confirms that a perfect level 1 is not strictly required before starting level 2. That flexibility is useful, but an unusual pattern, such as strong level 3 answers on top of a weak level 1, is a signal to look again at the answers.

Measuring progress: percent to target and progress to date

Raw scores can hide what matters. The SAMM project published two relative metrics in 2025. Percent to target compares current answers with target answers activity by activity: for each activity the gap is the target value minus the current value (or zero if you already meet or exceed the target), and the metric is one minus the total gap divided by the total target value. Over-achieving on one activity does not cancel a gap on another. Progress to date compares how far you have moved since the baseline: the improvement since the first assessment divided by the distance between the baseline and the target. If your baseline overall score was 0.8, your target is 1.8 and you are now at 1.3, your progress to date is 0.5 divided by 1.0, which is 50 %.

Tools

The official SAMM Toolbox is a spreadsheet with an interview sheet, automatic scorecards and a roadmap sheet, available for Excel and Google Sheets. SAMMwise is an open, self-hosted web tool for running assessments. Commercial tools also exist, such as SAMMY from Codific, one of the project's sponsors. Whatever the tool, the model, questions and scoring rules are the same.

Is there a SAMM certification?

No. OWASP does not certify organisations against SAMM, and there is no accredited auditor scheme or official certificate of conformance. A SAMM score is a self-improvement and communication tool. When a supplier tells you "we are SAMM level 2", ask what scope was assessed, who assessed it, when, with what evidence, and for the full scorecard, because a single number says little.

For people, the project offers a free, self-paced SAMM fundamentals course and various trainings, and it publishes a directory of practitioners who offer SAMM assessments, roadmaps or tools. OWASP states that being listed is not an endorsement and that users must vet practitioners themselves. Course completion, conference trainings and directory listings are useful, but none is a professional certification issued by OWASP.

The benchmark

The SAMM benchmark initiative invites organisations to contribute anonymised assessment results. Once enough data exists for a sector, you can compare your scores with peers, which helps set realistic targets and show management where you stand. The first benchmark report was presented in 2024. Contributing is voluntary and, as the guidance suggests, best done after you have completed a full cycle and trust your own data.

Lesson 6 – Worked example

This example follows a fictional company through its first SAMM cycle. The numbers are illustrative but use the real scoring rules.

The organisation

Harbourline is a mid-sized logistics company with about 120 developers in 14 product teams. Its customer portal and shipment-tracking APIs handle personal data and payment references. After a large customer sent a detailed supplier security questionnaire and a competitor suffered a public breach, the CTO asked the new AppSec lead, Mei, to "find out how good we really are and give me a two-year plan".

Step 1 – Prepare

Mei resists the temptation to assess all 14 teams at once. The teams use the same CI/CD platform and the same release policy, but the portal and API teams follow a common way of working while the warehouse teams use a different vendor platform. She chooses as first scope the four teams of the Customer Platform group, which share procedures and handle the most sensitive data. She documents the goals (a baseline, a two-year target, and honest answers for customer questionnaires), the scope and the stakeholders: the CTO as sponsor, the platform engineering lead, the four team leads, the QA lead, the head of IT operations and the data protection officer. She runs a 45-minute briefing that explains SAMM and stresses that the scores describe processes, not individual people.

Step 2 – Assess

Mei runs six interviews over two weeks, each focused on a subset of practices and the right people: Governance with the CTO and herself, Design with architects and team leads, Implementation with platform engineering, Verification with QA, Operations with IT operations and the data protection officer. For each question she reads the quality criteria aloud, asks for examples and notes evidence. For a few answers she checks artefacts: the pipeline configuration, the ticket system and the incident log.

Some observations: the teams run a dependency scanner in every pipeline, but nobody reviews the findings, so the quality criteria for reviewing dependencies are not met. Threat modeling happened once, for the payment flow, but the result was never saved. Security defects are tracked in the normal backlog without a security label, so nobody can count them. Incident response relies on two experienced operations staff and an informal chat channel.

Here is part of the resulting scorecard for the Threat Assessment practice. In the Application Risk Profile stream, a basic risk classification exists for about half of the applications, so level 1 gets 0.5; there is no inventory of profiles (level 2 gets 0) and no periodic review (level 3 gets 0). The stream score is 0.5. In the Threat Modeling stream, the single unsaved session does not meet the criteria, so level 1 gets 0, and the stream score is 0. The Threat Assessment practice score is the average of 0.5 and 0, which is 0.25.

Across all fifteen practices, the picture is uneven: Secure Build scores 1.0 thanks to the automated pipeline, Secure Deployment 1.25, Security Testing 0.75, while Strategy and Metrics, Threat Assessment, Security Requirements and Defect Management are all at or below 0.5. The overall score is 0.7.

Step 3 – Set the target

Mei, the CTO and the team leads discuss the results with the company's risks in mind: personal data, payment references, customer contracts and a growing API surface. They agree a two-year target overall of about 1.6, but distributed with intent. Threat Assessment, Security Requirements, Defect Management and Incident Management get the largest increases. Secure Build and Secure Deployment, already reasonable, rise only modestly. Operational Management gets a target driven by the data protection officer's priority of knowing where personal data lives. Almost all target activities are at levels 1 and 2; the only level 3 activity in the target is periodic review of application risk profiles, because the portfolio changes quickly.

Step 4 – Define the plan

The roadmap has four phases of six months:

1. Phase 1 – Foundations: appoint a security champion in each team; run awareness training for everyone; create a security label and a simple severity scale for defects; classify all applications by risk; save every threat model in the repository.
2. Phase 2 – Requirements and design: introduce a short list of standard security requirements referenced from the Definition of Done; run threat modeling for every high-risk change using a common template; start reviewing dependency scanner findings with agreed rules.
3. Phase 3 – Verification and operations: derive security test cases from the standard requirements; write an incident response plan and run a tabletop exercise; agree fix-time targets for security defects by severity.
4. Phase 4 – Measure and extend: define basic security metrics and report them quarterly; build an inventory of risk profiles and review it every six months; extend the approach to the warehouse teams with a separate scope.

Each item has an owner, an estimate and the SAMM activity it supports. Quick wins such as the defect label and champion network come first because they cost little and make later steps easier.

Steps 5 and 6 – Implement, roll out and re-assess

After six months Mei repeats the assessment with the same questions and interview approach. The champions are in place and threat models are now saved, so Threat Modeling level 1 earns 0.5; risk classification now covers most applications, so Application Risk Profile level 1 earns 1. The Threat Assessment practice rises from 0.25 to 0.75. The overall score moves from 0.7 to 1.0. With a baseline of 0.7 and a target of 1.6, progress to date is 0.3 divided by 0.9, roughly 33 %, which is on track for a four-phase plan. Mei's quarterly report to the CTO shows the scorecard, the progress metric, a list of completed roadmap items and two adoption measures: the share of high-risk changes with a saved threat model, and the median time to fix critical security defects.

When the next customer questionnaire arrives, Harbourline can answer with specific, evidenced statements about its practices and a credible improvement plan, rather than vague promises.

Lesson 7 – Relationship to other standards and frameworks

SAMM is one tool among several. Knowing how they differ helps you pick the right one for each question and avoid duplicate work.

Framework	Owner	What it is	How it relates to SAMM
BSIMM (Building Security In Maturity Model)	Commercial study, now published by Black Duck	Descriptive: an annual study of the software security activities that participating firms actually perform, with how common each one is.	Shares SAMM's early roots but answers "what do others do?" rather than "what should we do next?". The SAMM project publishes a BSIMM-to-SAMM mapping.
NIST SSDF (SP 800-218)	NIST, United States	A set of secure development practices in four groups: prepare the organisation, protect the software, produce well-secured software, respond to vulnerabilities. Widely used in software supply-chain attestations.	Says what outcomes are expected; SAMM measures how mature your practices are. A mapping created with NIST's informative reference programme links the two.
OWASP ASVS (Application Security Verification Standard)	OWASP	Detailed, testable security requirements for applications, in three verification levels.	Works at application level. SAMM's Security Requirements and Requirements-driven Testing practices can use ASVS as their source of requirements and test cases.
ISO/IEC 27001	ISO and IEC	Certifiable standard for an information security management system; Annex A includes controls on the secure development lifecycle.	Covers the whole organisation and offers certification. SAMM gives depth on software practices and a way to plan and evidence improvements under the ISMS.
Microsoft SDL	Microsoft	A published secure development lifecycle with recommended practices for product teams.	A concrete process; SAMM can measure how mature an organisation's SDL-style practices are. A mapping is published.
IEC 62443-4-1	IEC	Secure product development lifecycle requirements for industrial automation and control system suppliers, used for certification.	Included in the SAMM mappings spreadsheet; SAMM can help an industrial supplier find gaps before a formal 62443 assessment.

How to combine them

A practical pattern is to use SAMM as the backbone of the software security programme, because it covers all five business functions and provides a simple way to measure and plan. Plug in ASVS where SAMM asks for security requirements and requirements-driven testing. Use the NIST SSDF mapping when customers or regulators ask for SSDF alignment or attestations. Feed SAMM evidence into the ISO/IEC 27001 management system, where an auditor checks controls and continual improvement. Use BSIMM data, if available, as a reality check on how peers invest.

The SAMM website also links each stream to further standards through OpenCRE (Open Common Requirement Enumeration), a community project that connects related requirements across standards such as the ISO/IEC 27000 family, PCI DSS, ASVS and NIST SP 800-53. These links are helpful for finding related requirements, but they are cross-references rather than formal equivalence. Two frameworks covering the same topic rarely demand exactly the same thing.

Other OWASP models

OWASP hosts other maturity models, for example the DevSecOps Maturity Model, which goes deeper into pipeline and platform automation. Such models can complement SAMM for specialised areas, but SAMM remains OWASP's broad, organisation-level model for software assurance.

Common pitfalls and best practices

Pitfalls

• Scope too wide on the first attempt – assessing teams that work in very different ways produces averaged scores that describe nobody and lead to plans nobody owns.
• Treating the score as the goal – chasing a high number encourages generous answers and paper activities. The score is a means to discuss risk and progress, not a trophy.
• Ignoring the quality criteria – answering "yes" because a tool exists or a document was written once, even though the criteria are not met, inflates scores and hides real gaps.
• Aiming for level 3 everywhere – SAMM is risk-driven. Uniformly high targets waste money on low-risk areas and overload teams.
• Emailing the full questionnaire – about 90 questions sent without explanation lead to fatigue and inconsistent interpretation across teams.
• Calling SAMM a certification – presenting a self-assessed score to customers as if it were audited misleads them and damages trust when questioned.
• One assessment, no follow-up – a single snapshot without a roadmap, owners and a re-assessment date changes nothing.
• Undocumented judgement calls – if nobody recorded why an answer was chosen, the next assessment cannot be compared with the baseline.

Best practices

• Start small and representative – pick a willing group of teams that work in a similar way and whose experience others can learn from, then extend.
• Interview, do not just survey – explain each question and its criteria, ask for examples, check key answers with evidence and with more than one person.
• Keep the method consistent – same questions, same interviewer approach, same rules for partial credit and non-applicable activities in every cycle.
• Set targets from risk – link each target to a business risk, contract or regulation, and favour broad level 1 and 2 coverage before level 3.
• Plan in phases with quick wins – four to six phases, early awareness and simple changes, dependencies respected, effort balanced across phases.
• Use champions and existing rituals – carry practices into teams through security champions, refinement, retrospectives and the Definition of Done.
• Report relative progress – show percent to target and progress to date alongside the scorecard, plus a few adoption measures.
• Reuse mappings – use the published SAMM mappings to answer SSDF, ISO/IEC 27001 or customer questions without repeating the assessment.

Summary and key takeaways

• OWASP SAMM is a free, open, prescriptive maturity model for software security; the current model is version 2 (released 2020, maintained through release 2.2.0 in 2026), with no official certification.
• The model has five business functions, fifteen security practices, two streams per practice and three maturity levels per stream, giving 90 activities.
• Level 1 is ad hoc and best effort, level 2 is consistent and repeatable, level 3 is continuously improved through feedback.
• Each activity is measured by a question with quality criteria; answers are worth 0, 0.25, 0.5 or 1, so SAMM measures both quality and coverage.
• Stream scores are sums of three levels (0 to 3); practice scores are averages of two streams; higher-level scores are averages on the same scale.
• The improvement cycle is prepare, assess, set the target, define the plan, implement, roll out, then re-assess.
• Targets should follow risk; most organisations focus on levels 1 and 2 and use level 3 selectively.
• SAMM complements BSIMM, the NIST SSDF, OWASP ASVS and ISO/IEC 27001: it is the measuring and planning backbone, the others supply requirements, data or certification.

Reflection questions

1. Which scope would you choose for a first SAMM assessment in your organisation, and how would you check that everyone in that scope really works in the same way?
2. Pick one practice you know well. For each of its two streams, which level do you think your team reaches today, and what evidence would convince an independent assessor?
3. Your sponsor wants "level 3 in everything within a year". How would you explain a risk-driven target instead, and which three practices would you prioritise for your context?
4. Design a first roadmap phase of six months for your team. Which quick wins would you include, and which dependencies would you have to respect?
5. A customer asks whether you comply with the NIST SSDF and whether you are "SAMM certified". How would you answer both questions honestly using your SAMM results?

Further reading and official sources

• OWASP SAMM – The Model (business functions, practices, streams and activities) – OWASP SAMM project
• OWASP SAMM – Getting started: the six-step improvement cycle – OWASP SAMM project
• OWASP SAMM – Assessment guide – OWASP SAMM project
• SAMM Scoring: Percent to Target and Progress to Date – OWASP SAMM project
• owaspsamm/core – model data and release history – OWASP SAMM project on GitHub
• OWASP SAMM – Mappings to other frameworks – OWASP SAMM project
• OWASP SAMM project page – OWASP Foundation
• Secure Software Development Framework (SSDF) – NIST Computer Security Resource Center

Original tutorial by xOps School (DevOpsSchool Private Limited), written from public sources about OWASP SAMM. Not affiliated with or endorsed by the standard's owner; standard names are trademarks of their owners. Buy the official standard from its publisher for the authoritative text.