Skip to content
GoSentrix
Application SecuritySecurity Best Practices

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

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.