Secure SDLC with OWASP SAMM: a practical start
A secure SDLC does not start with a tool purchase. It starts with an honest picture of what your teams already do, and OWASP SAMM is a good way to get one: measure your current maturity across its fifteen practices, choose two or three practices where the gap matches your real risk, improve those, and measure again. The score is the by-product; the change in how software gets built is the point.
What is OWASP SAMM?
OWASP SAMM is an open maturity model for software security. It groups fifteen security practices under five business functions — Governance, Design, Implementation, Verification and Operations — and defines three maturity levels for each practice. Each practice splits its activities into two streams, and each level asks for more than the one below. The model is published by OWASP at owaspsamm.org, is technology and process agnostic, and was in version 2 as of September 2026.
| Business function | Security practices |
|---|---|
| Governance | Strategy & Metrics; Policy & Compliance; Education & 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 |
What it is not: a compliance scheme. There is nothing to pass, and a SAMM score means little outside your own organization. Its value is as a shared vocabulary and a way to see progress.
How do you take a SAMM baseline?
SAMM’s own quick start guide has six steps: prepare, assess, set the target, define the plan, implement, and roll out. The first four are planning work that the guide puts at one to two days of effort. In practice:
- Scope narrowly. One product or one team. An organization-wide average hides the team that ships nothing securely.
- Interview, do not survey. The SAMM toolbox pairs each question with quality criteria. If the criteria are not fully met, the answer is “no”.
- Ask for evidence. A threat model, a pipeline configuration, a closed finding. A practice that exists only in someone’s memory does not exist.
Who should run the assessment? Someone who can ask engineers direct questions and will record “no” when the evidence is not there. For the first round, an outside facilitator helps, so the baseline is not a team grading its own work.
Which two or three practices first?
Assess one product or team honestly, then pick two or three practices where a gap maps to something that has already hurt you or is about to. Spreading effort across all fifteen at once improves the score and changes little. For most product teams, the useful first picks are:
- Threat Assessment, because design flaws are the most expensive to fix late. A lightweight version is described in what a threat model looks like.
- Secure Build, because the pipeline and its dependencies are where supply chain problems enter — software supply chain failures now sit in the OWASP Top 10:2025.
- Defect Management, because findings that are not tracked to closure make every test you buy less valuable.
If nothing tests your software today, Security Testing may outrank all three. Choose from evidence — recent incidents, repeated findings, customer questions — not from which practice sounds most mature.
How do you measure SAMM progress?
Do you need the top level in every practice? Not in every practice. SAMM itself does not insist on the maximum level everywhere; each organization sets a target per practice that fits its risk. A sound first level across the practices that matter beats level three in one corner. The SAMM project’s own description leaves the target to each organization. Set a target level per chosen practice, turn the gap into a short roadmap with owners, and re-assess the same scope on a fixed cadence with the same questions. Pair the score with one or two operational measures you already collect, such as how long security findings stay open. A rising score with no change in those numbers is a sign the assessment has become a paperwork exercise.
Designing and running this alongside your engineers is part of secure development.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What is OWASP SAMM?
OWASP SAMM is an open maturity model for software security. It groups fifteen security practices under five business functions — Governance, Design, Implementation, Verification and Operations — and defines three maturity levels for each practice.
Do we need to reach the highest maturity level?
Not in every practice. SAMM itself does not insist on the maximum level everywhere; each organization sets a target per practice that fits its risk. A sound first level across the practices that matter beats level three in one corner.
Where should we start?
Assess one product or team honestly, then pick two or three practices where a gap maps to something that has already hurt you or is about to. Spreading effort across all fifteen at once improves the score and changes little.
Who should run the assessment?
Someone who can ask engineers direct questions and will record “no” when the evidence is not there. For the first round, an outside facilitator helps, so the baseline is not a team grading its own work.
Start with a baseline
Tell us which product or team you want to look at first. The reply is a plan for the baseline and the questions it will ask. More of our writing is indexed at writing.