The OWASP DevSecOps Maturity Model (DSOMM)
The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation dedicated to improving the security of software through open-source projects, community-led initiatives, and educational resources. It's a vendor-neutral organization, meaning it does not endorse commercial products or services, ensuring that its guidance remains unbiased and community-driven.
OWASP is best known for the OWASP Top 10, a regularly updated list of the most critical web application security risks.
So I recently published my third book title DevSecOps in Oracle Cloud. This is a huge book hitting 640 pages in length. A lot of topics were covered, namely DevSecOps concepts, open-source tools, and obviously Oracle Cloud services that enable DevSecOps. It was through my book research and subsequent conference presentations that I came across and learned about the OWASP DevSecOps Maturity Model (DSOMM).
(On a side note, here's another blog post of mine that describes the differences between DevSecOps and SecDevOps.)
From On-Prem to DevSecOps
Every organization is at a different stage in their DevSecOps journey. Here's a diagram I created that shows the typical long-term evolution an organization may go through as it matures towards DevSecOps.
If you're still in the early phases of your cloud journey, DevSecOps will likely not be on your mind. You have enough on your plate establishing your cloud standards, best practices, and governance. But as you continue to mature, you start introducing DevOps, hopefully followed by DevSecOps.
I used this diagram in several of my presentations on the topic, and I feel it is a self-explanatory way of depicting the challenges, needs, and enablers of each phase of the journey.
Introducing DSOMM
I came across the DevSecOps Maturity Model (DSOMM) in 2025, but it was originally introduced by OWASP in 2017.
The DSOMM is a framework designed to integrate security into DevOps practices effectively. It provides a structured approach to assess and enhance security measures across the software development lifecycle, ensuring that security is not overlooked during the implementation of DevOps strategies.
I love the graphical depiction of the model. Here, it provides a visual representation of your DevSecOps maturity level in an easy to understand color-coded diagram. The greener, the better. The darker the green, the more mature you are. More greens in the outer layers, the higher your mature level is.
DSOMM includes 6 core dimensions:
- Build & Deployment
- Culture & Organization
- Implementation
- Information Gathering
- Test & Verification
Each dimension includes multiple sub-dimensions, shown in the figure above.
An interactive model where you can build your own representation can be found at dsomm.owasp.org. When clicking on a cell that represents the subdimension and maturity level, you are presented with a lifecycle toggle.
For example, the following diagram shows how when clicking on the cell (see #1 in the diagram) representing the Deployment subdimension at Maturity Level 5, you are presented with a deployment initiative (see #2), in this case, Blue/Green Deployment, and you can use toggle to indicate where you are in the lifecycle of this effort. Based on the whether you just started or if its fully implemented, the shade of green will change.
What next?
The following figure shows where you ideally want to be, which is seeing dark green on every sub-dimension in the outermost layer. Though practically impossible to achieve, the goal is to at least aim for it.
But what are you supposed to do with this model?
Go online and you'll read that it's a "framework" or a "roadmap" or an "assessment" or a "benchmark." None of these are necessarily wrong, as the OWASP DSOMM ultimately aims to help your organization incrementally improve security within DevOps practices.
But here is a simple actionable plan I suggest:
- Assess your current environment (don't overthink it), and use dsomm.owasp.org to create a visual snapshot of your current state (creating a radar diagram like the above).
- Use it to identify major gaps across various dimensions, and prioritize high-impact security activities that should be focused on.
- Repeat every 6 months, and compare to previous snapshots over time.
I keep using the word "journey" when it comes to DevSecOps, because it truly is. Startups shouldn't aim for Maturity Level 4 across the board. DSOMM is initially most effective when you pick Maturity Level 1 for everything and only Maturity Level 3 for your highest-risk areas.
One last note, you might find in some DSOMM documentation that Maturity Levels are described between 1 and 4 and in others between 1 and 5, the latter being the more recent one. But don't sweat it too much.