Key Facts
- Regulator
- OWASP Foundation (OWASP Lab project)
- Latest version
- 5.1.0
- Effective
- 21 September 2026
- Official text
- owasp.org ↗
What is DSOMM?
DSOMM, the OWASP DevSecOps Maturity Model, is a framework for assessing, improving and prioritising security activities in the software development cycle. The OWASP Foundation publishes it as a Lab project. It applies to technical teams that build and ship software, and to the security staff who support them.
DSOMM stands for DevSecOps Maturity Model. The OWASP project page lists it as an OWASP Lab project led by Timo Pagel and Aryan Prasad. The framework holds a number of security activities, grouped by dimensions and maturity levels, so a team can see which activities it already performs and which to take on next.
The current model release is DSOMM 5.1.0, published in September 2026.
Why it matters
A pipeline with scanners in it feels secure. Whether the practice around it is mature is a different question.
DSOMM exists to answer that question in three ways:
- Assess. The framework lists security activities across the software development cycle, so a team can compare its own practice with a shared reference rather than with opinion.
- Improve. Activities sit at maturity levels, which shows the team what a more developed practice looks like.
- Prioritise. With many possible activities and limited engineering time, the levels help a team choose what comes next.
A maturity score nobody acts on is only a number.
Who it applies to
DSOMM is written for technical teams focused on implementing secure software. That means engineering leads, DevOps and platform engineers, and the security staff who work with them. A firm that buys all of its software and writes none has little to assess.
The framework is DevOps-focused. It concentrates on activities that integrate security directly into DevOps workflows.
DSOMM is voluntary as far as we can establish. We found no regulator or law that requires it, and the project describes it as a framework that helps organisations assess, improve and prioritise. Treat it as an internal choice unless a contract or customer names it.
OWASP SAMM is the nearest relative. The DSOMM usage page explains that SAMM has a broader scope, covering governance, compliance and risk management across the whole organisation, and that SAMM holds Flagship status where DSOMM is a Lab project. The choice follows the question you are asking: pipeline practice, or organisation-wide assurance.
For an ISO 27001 holder, the closest link is Annex A control A.8.25, secure development life cycle. ISO 27001 asks you to run one but gives no maturity scale for the engineering activities inside it. DSOMM can supply that view of the technical side, but it does not replace the management system described in the ISO 27001 vault.
The UK position
No UK law or regulator names DSOMM, and we found no UK regime that references it. A UK firm meets DSOMM by choice, when an engineering or security team adopts it to structure its own improvement work. It is not a UK compliance obligation.
Key requirements
The project documentation describes DSOMM as a framework for assessment, and we found no certification route. What a reader needs to know is how it is organised.
The current model groups its activities into six dimensions:
- Agentic AI: securing the AI tools and agents used in software work, from data leak prevention to sandboxing and permissions.
- Build and Deployment: security in the CI/CD pipeline and the deployment process.
- Culture and Organization: culture, education and the processes that support security work.
- Implementation: secure coding and infrastructure hardening.
- Information Gathering: data for threat analysis, risk assessment and metrics, including logging and monitoring.
- Test and Verification: testing that checks security measures work.
Each dimension splits into sub-dimensions, and each activity within them sits at a maturity level.
Maturity levels
Maturity level 0 covers the preparation before you use DSOMM, such as getting stakeholders on board, which the project says will ease your path. The activities themselves sit at levels 1 to 5. In the Logging sub-dimension, for example, centralised system logging is a level 1 activity and correlation of security events is level 5.
A maturity model with no sponsor is a spreadsheet.
Licence and reuse
The project licenses its code under GPL v3 and its intellectual property under Attribution-ShareAlike. If you adapt DSOMM content for internal assessments or published material, check the licence terms on the project page first.
Frequently asked questions
OWASP SAMM measures software assurance across the whole organisation, and the DSOMM project describes it as written by security specialists for security specialists. DSOMM goes lower in the technology stack and is written for the engineers who build and run the pipeline. The two are complementary: the DSOMM project points to a talk by Timo Pagel on using DSOMM alongside SAMM.
The current DSOMM model release is 5.1.0, published on 21 September 2026. The project releases the DSOMM application and the activity model separately, each with its own release notes, and new releases arrive often. When you report a DSOMM assessment, record the model version you assessed against so that later results compare like with like.
No. ISO 27001 Annex A control A.8.25 asks for a secure development life cycle but names no maturity model. A certification auditor assesses your ISMS against ISO 27001, not your DSOMM levels, so a DSOMM assessment is supporting material for A.8.25 rather than something the audit requires.
The DSOMM site lets a team mark each activity as not implemented, started, partly implemented or fully implemented. The public site keeps that progress only in your browser, so teams that need a shared record export it as a YAML file or run their own DSOMM instance, which the project supports through Docker. Evidence that an activity is done goes into that file.