The OWASP DevSecOps Maturity Model (DSOMM) is a framework for assessing and improving DevSecOps practices.
With methods for communicating goals to stakeholders and a roadmap for progressively enhancing application security, the DSOMM empowers you to reduce development time and costs, increase agility and innovation, gain better visibility into security risks, improve collaboration, and achieve compliance and governance goals. Simply put, with the OWASP DevSecOps Maturity Model, you can shift your security left and prevent breaches at any stage of the software development lifecycle.
Let’s walk through the maturity levels of the DSOMM to learn how to bolster security while streamlining security processes.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet
Initial stage: Siloed teams and reactive security
Organizations that don’t implement DevSecOps have siloed development, operations, and product owners. Releases follow a waterfall model with manual processes, meaning security considerations are pushed to the end of the development cycle. The end result is that vulnerabilities are discovered late and require costly fixes.
Level 1: Basic understanding of security practices
During this stage of the DSOMM, security practices are inconsistent and informal, varying by project and sprint. Developers may have some awareness of basic security threats, but the organization lacks a systematic approach to identifying and mitigating these threats during development.
Processes rely heavily on individual experience rather than structured methodologies, and security training occurs ad-hoc without a formal schedule. Security experts are only consulted when explicitly requested, and processes are often undocumented, leading to inadequate historical data for improvement.
Setting up more robust processes
Threat modeling should be performed continuously throughout the development process, and it should become more detailed over time. Update the threat model after significant events such as new feature planning, version releases, security incidents, or infrastructure changes.
Conduct ad-hoc threat modeling for high-risk applications using simple checklists like STRIDE. Focus on whiteboarding general data flows and high-level system architecture, and integrate basic threat modeling into the Definition of Done to ensure security is consistently addressed. These steps establish a security-first mindset and lay the groundwork for more advanced practices as the organization matures.
Next, establish basic business continuity and disaster recovery practices (like failovers and backups) to mitigate existential threats.
Implementation
Use this checklist for Level 1 implementation during each phase of the SDLC:
Infrastructure
Basic access control lists (ACLs) and multi-factor authentication (MFA)
Edge encryption for external communication
Development
Version control for artifacts, application, and infrastructure code
Prevention of accidental updates or skipped CI/CD checks
Scanning for secrets in code and container images
Enforced commit signing
Testing and verification
Opportunistic and discretionary testing
Testing of major functionality and testing for obvious vulnerabilities
Building and deployment
Automated CI/CD process
Defined build process to reduce manual intervention
Security patch policy for prioritizing, scheduling, and validating patches
Use of tools like Dependabot for managing third-party dependencies
CI/CD Pipeline Security Best Practices [Cheat Sheet]
In this 13 page cheat sheet we'll cover best practices in the following areas of the CI/CD pipeline: Infrastructure security, code security, secrets management, access and authentication, monitoring and response.
Download Cheat Sheet
Monitoring
Centralized system logging
Simple budget metrics tracking
Basic system metrics monitoring
Level 2: Adoption of basic security practices
At this level, each software development team designates a "security champion" to act as a liaison between information security and the team. Security champions receive specialized, ongoing training to become subject-matter experts, ensuring they stay up-to-date on the latest security threats and practices. They assist in researching, verifying, and prioritizing security defects, and participate in risk assessments, threat assessments, and architectural reviews to improve application resilience and reduce attack surfaces.
All team members involved in software management, development, testing, or auditing should undergo regular security training. This training raises awareness of security threats, best practices, and secure design principles such as least privilege, defense-in-depth, and the OWASP Top 10 vulnerabilities.
Implementation
Infrastructure
Virtualized environments for applications
Automated backups and rollback procedures
Baseline hardening that adheres to security best practices
Separate test and production environments
Resource limitation to prevent denial-of-service issues
Development
Unit testing for important security features
Building and deployment
Virtual environments for managing third-party systems and libraries
Pinning artifacts and creating a software bill of materials (SBOM)
Nightly builds for base images and use of distroless images
Secrets management through environment variables
Clear decommissioning process for unused resources
Testing and verification
Shift left in CI/CD pipelines to enforce hardening best practices
Simple visualization and reporting tools for vulnerabilities
Dynamic component coverage, including client-side components
Role-based testing
Exposed services testing
Monitoring and measurement
Improved visualizations for easier anomaly detection
Proactive alerts for security incidents
Level 3: High adoption of security practices
At this level, standardization, automation, visibility, and transparency enable learning and continuous improvement. Tests, reports, metrics, and alerts are regularly updated for relevancy.
Threat modeling is standardized, including the assessment of business functionality during product backlog creation. User stories are created alongside abuse stories, ensuring security considerations are a top priority during development.
Security education is highly interactive and gamified with activities like build-it / fix-it contests, lessons-learned sessions, mob hacking, and bug bashes. Security peer reviews occur for all infrastructure and application code, and a change management process logs all system changes.
Implementation
Infrastructure
All components are "secure-by-default"
Firewalls on both ingress and egress traffic
Web application firewall (WAF) for input protection
Encryption for internal services (e.g., mTLS)
Immutable infrastructure as code and policy as code with static analysis and tests
Development
Integration of security checks into IDEs using linting plugins
Testing and verification
Enhanced CI/CD pipeline guardrails
Restriction of syscalls using mechanisms like seccomp
Testing for complex authentication and authorization vulnerabilities
Inclusion of internal or hidden functionality in testing
Extension of software composition analysis and static analysis to client-side software
Integration tests for secure communication in distributed architectures
Effective vulnerability management systems
Application hardening as per AASVS level 2
Building and deployment
Comprehensive SBOM, vulnerability assessment, and code/artifact signing
Encrypted and restricted access to secrets
Rolling deployments to minimize disruptions
Monitoring and measurement
Reports on patch management and threat response
Improved time to recovery through organized observability data
Level 4: Very high adoption of security practices
Here, the team has a deep understanding of security standards and can come up with more advanced abuse stories. Threat modeling is comprehensive and fully integrated with the SDLC. CI/CD features comprehensive automated guardrails that ensure alignment with a full range of security and compliance requirements and produce easily understood and operationalized reports and metrics.
Security is no longer siloed; it is seen as the responsibility of the entire team. The focus is on getting early feedback and fast remediation. Teams engage in war games and mutually test the security of systems they are not directly developing. Experts are regularly called in to educate the team on the latest and best practices.
Implementation
Infrastructure
Production-like development and test environments
Testing and verification
Advanced testing techniques (smoke testing, chaos testing)
Comprehensive coverage using various static analysis and security scanners
Informative and reproducible tickets for easy prioritization and fixing
Building and deployment
Promotion of the same artifact through lower environments
High release frequency with short-lived artifacts and feature toggles
Monitoring and measurement
Consolidated and contextualized metrics
Visualization of defense metrics
Level 5: Advanced deployment of security practices at scale
At this level, the team is already operating at a high level of security but needs to implement formal processes to scale for a larger organization (more personnel, more systems). Periodic security reviews of code and architecture are conducted among security experts, developers, and operations.
Implementation
Development
Comprehensive, enforced secure coding guidelines
Testing and verification
Tests with telemetry for performance and security insights
Very high test coverage with almost all defects fixed
Building and deployment
Deployment of only tested, hardened, and signed artifacts
Advanced deployment techniques (canary, blue-green)
Monitoring and measurement
Aggregated and centralized data from multiple sources
Proactive threat response using automated log and metric auditing
How can Wiz help?
Wiz supports the OWASP DevSecOps Maturity Model by integrating security practices throughout the software development lifecycle (SDLC) and ensuring continuous security monitoring and enforcement. Here are some key ways Wiz aligns with the model:
Shift Left Security: Wiz integrates with your CI/CD pipeline, IDE, and VCS to detect and remediate vulnerabilities, misconfigurations, and secrets early in the development process. This proactive approach helps prevent security issues from reaching production.
Continuous Monitoring: Wiz continuously scans your cloud environment for vulnerabilities, misconfigurations, and other security risks. This ensures that any deviations from security baselines are detected and addressed promptly.
Automation and Integration: Wiz offers built-in integrations with ticketing, workflow, and messaging applications, enabling automated routing of security issues to the appropriate teams. This facilitates efficient remediation and policy enforcement.
Unified Security Policies: Wiz enforces a homogeneous set of security policies across your development pipeline and cloud environment. This ensures consistency and reduces the risk of security drift.
Comprehensive Risk Analysis: Wiz uses a security graph to model your cloud architecture and identify the most critical risk combinations. This helps prioritize remediation efforts based on the potential impact.
Secure your SDLC from start to finish
See why Wiz is one of the few cloud security platforms that security and devops teams both love to use.
