How Organizations Can Benchmark, Measure, and Improve Their DevSecOps Capabilities
The OWASP DevSecOps Maturity Model (DSOMM) is a framework for assessing and improving DevSecOps practices.
GoSentrix Security Team
Major Takeaway
The OWASP DevSecOps Maturity Model (DSOMM) provides a structured framework for evaluating how effectively an organization integrates security into its software delivery lifecycle. It helps organizations move from ad-hoc, manual security practices toward fully automated, scalable, and measurable DevSecOps workflows.
DSOMM is widely adopted because:
- It is practical — focuses on real engineering behaviors
- It is incremental — maps a clear path to DevSecOps maturity
- It is tool-agnostic — works with any tech stack or cloud platform
- It is aligned with modern software delivery — CI/CD, cloud-native, IaC, containers, AI-driven pipelines
Table of Contents
What Is the OWASP DSOMM?
The DevSecOps Maturity Model is an open framework from the OWASP community that:
- Identifies DevSecOps capabilities across key areas
- Defines maturity levels from basic to advanced
- Provides measurable behaviors, not just vague goals
- Enables organizations to benchmark their current state
- Provides a roadmap to improve security automation and culture
DSOMM focuses on answering:
“How mature is our DevSecOps implementation — and how can we improve it?”
It is used as:
- A maturity scoring model
- A gap analysis tool
- A roadmap planning framework
- A communication tool between engineering & security
- A benchmark for compliance and audits
DSOMM Maturity Levels
The OWASP DevSecOps Maturity Model defines four levels of maturity.
Each level builds on the previous one.
Level 0 — Initial / Ad-Hoc
Security is mostly reactive or manual.
- Security is not part of CI/CD
- No automation
- Siloed security team
- Rely heavily on manual reviews and one-off scans
- No metrics or visibility
Teams often struggle with:
- Vulnerabilities discovered late in production
- Slow security bottlenecks
- Inconsistent practices
Level 1 — Managed / Defined
Security processes are established and partially integrated.
- SAST, SCA, IaC checks integrated into pipelines
- Documented security policies
- Developers receive security training
- Basic CI/CD security controls: secrets scanning, linting, dependency checks
- Threat modeling begins, but inconsistently
Organizations here start to shift-left, but still rely on security teams for bottleneck reviews.
Level 2 — Measured / Automated
Security is largely automated and treated as part of the engineering workflow.
- Automated SAST, SCA, IaC, container scanning
- Automated DAST or API testing in CI/CD
- Infrastructure-as-code and policy-as-code enforcement
- Runtime protections (e.g., WAF, API gateways, container hardening)
- Continuous monitoring and telemetry
- Regular threat modeling integrated into planning
- Vulnerability SLAs measured and enforced
- Developers own remediation with security coaching
Security becomes a shared responsibility across development, operations, and security.
Level 3 — Optimized / Continuous
Security is fully integrated, adaptive, and continuously improving.
- End-to-end automation (build → test → deploy → monitor)
- Security-as-code across environments (OPA, Sentinel, Kyverno)
- Supply chain security integrated (SBOM, signed builds, provenance)
- Automated anomaly detection on pipelines & workloads
- Advanced runtime protections (eBPF, behavior-based detection)
- Full integration of DevSecOps metrics → KPIs
- Chaos engineering with security test scenarios
- AI-driven triage and automated remediation workflows
Teams here achieve continuous security, not just continuous delivery.
DSOMM Core Capability Areas
DSOMM evaluates maturity across several categories, including:
1. Culture & Governance
- Security ownership
- Leadership support
- Training
- Secure coding standards
- Security champions program
2. Build & Deployment Pipeline Security
- CI/CD hardening
- Secrets management
- Build attestation
- Dependency scanning
- Artifact signing
3. Code Analysis & Testing
- SAST & SCA
- Policy-as-code
- Linting and secure coding checks
- Fuzzing
- Code review security steps
4. Runtime & Operational Security
- Container runtime security
- Cloud posture management
- Logging & monitoring
- Runtime defenses (WAF, RASP, eBPF)
- Incident response integration
5. Infrastructure & Cloud Security
- IaC scanning
- Cloud misconfiguration detection
- Zero-trust identity
- Immutable infrastructure
- Secrets rotation & access control
6. Application & API Security
- API discovery & testing
- Auth/Z testing
- DAST automation
- OWASP Top 10 integration
- Microservice boundary enforcement
7. Supply Chain Security
- SBOM generation
- Dependency validation
- Package trust policies
- Secure registries
- SLSA-aligned pipeline controls
8. Metrics & Continuous Improvement
- Vulnerability SLAs
- Mean-time-to-remediate (MTTR)
- SLO/SLA for security events
- DevSecOps maturity reviews
- Dashboards & risk scoring
How to Use DSOMM in Your Organization
Here’s how most organizations use the model:
Step 1: Assess Your Current State
Score each domain from Level 0 → Level 3.
Questions include:
- Are security controls automated?
- Do developers get instant feedback?
- Are pipelines protected?
- Are cloud configurations continuously checked?
- Do we measure risk outcomes?
Step 2: Identify Gaps
Highlight where you are below industry expectations.
For example:
- Automated IaC scanning missing
- No artifact signing
- No runtime threat detection
- Manually-managed secrets
- No SBOM or supply chain security
Step 3: Build a Roadmap
Prioritize improvements around:
- High-risk gaps
- Areas that unlock automation
- Developer experience impact
- Compliance requirements
Step 4: Integrate DevSecOps Across Teams
Promote collaboration across:
- Developers
- Platform engineering
- Security teams
- Cloud operations
- Architects
Step 5: Measure Progress Continuously
Use KPIs such as:
- MTTR for vulnerabilities
- Number of critical misconfigurations
- % of automated vs manual security tasks
- Escape rate (flaws reaching production)
- Pipeline security incidents
DSOMM is a maturity journey, not a destination.
Why DSOMM Matters for Modern Engineering Organizations
Adopting DSOMM helps organizations:
- Reduce vulnerabilities earlier
- Accelerate CI/CD without sacrificing security
- Minimize production incidents
- Strengthen cloud and supply chain posture
- Improve developer productivity
- Demonstrate compliance to auditors & leadership
It provides a realistic, structured path from manual security to fully automated DevSecOps programs.
Conclusion
The OWASP DevSecOps Maturity Model (DSOMM) is one of the most effective frameworks for measuring and improving your DevSecOps capabilities. It helps teams understand where they are, where they need to go, and how to build a culture of continuous, automated security across the SDLC.
Organizations that reach Level 3 maturity experience:
- Faster development cycles
- Fewer security issues
- Stronger cloud posture
- Better compliance and governance
DSOMM is not a checklist — it’s the foundation of a high-performing, future-ready DevSecOps organization.