From DSOMM Theory to Practical Enforcement: A DevSecOps Journey

At Jit, we have often spoken about different security frameworks and standards, and how they apply to practical security.  One of the aspects we like to look at closely when exploring security frameworks, is the way in which engineering teams can take these good practices and apply them to their day-to-day engineering work.  Essentially, how to codify or operationalize these practices.

Raz Probstein, Solution Engineer at Jit, recently gave talks at OWASP Global AppSec Tel Aviv and the OWASP London Chapter, about OWASP’s DevSecOps Maturity Model (DSOMM). In this post, we’d like to share a bit about what DSOMM is, why it’s interesting, and how engineering teams can take it from theory to practical implementation.

The OWASP DevSecOps Maturity Model (DSOMM) is a framework designed to help organizations integrate security into their DevOps processes systematically and incrementally. Created by the Open Web Application Security Project (OWASP), DSOMM provides a structured approach to assess and enhance security practices in DevSecOps environments.

The Essence of Security Maturity Models

Before we dive into DSOMM itself, it’ll be worthwhile to explore DSOMM in the context of other Security Maturity Models, even if these may not initially strike one as exhilarating. Yet, when properly implemented, Security Maturity Models wield significant transformative power within organizations. They facilitate meaningful discussions across different levels of technical understanding, from developers to C-level executives, by translating complex technical details into actionable insights and strategic decisions.

Leading Security Maturity Models

Let's take a look at some leading security maturity models:

• NIST and CMMI: These models offer structured levels but can be challenging to translate directly into actionable steps within modern agile environments.

• CSA (Cloud Security Alliance): Tailored specifically to cloud security but doesn't dive deep into DevSecOps.

• OWASP SAMM: Another OWASP framework, is somewhat more rigid and less flexible for rapid agile development cycles.

Why DSOMM?

The OWASP DevSecOps Maturity Model, or DSOMM, stands out by offering a flexible, iterative approach that aligns well with agile development practices. Unlike the rigid structures of some other models, DSOMM supports continuous adaptation and improvement.

DSOMM provides a clear pathway for organizations to integrate security into their DevOps practices, starting from basic levels and moving towards advanced integrations, through well-structured security implementation. It is also a good way for organizations to identify and measure progress through the maturity levels at their own pace, which makes the model adaptable to different organizational capacities and security needs, providing a good understanding of incremental Improvement. 

By involving multiple dimensions of the organization, DSOMM fosters a security-centric culture throughout the development process, alongside cross-organizational security awareness. As organizations climb the maturity levels, they gain better tools and processes for identifying, assessing, and mitigating security risks, which ultimately translates to better risk management overall.

What is DSOMM and How Does it Work?

Now that we’ve started with “The Why”, and we have a better understanding of the benefits of employing DSOMM, now we’ll dive into the specifics and how it actually works.  DSOMM organizes security practices across multiple dimensions, making it easier for organizations to assess their current capabilities and plan improvements systematically.



Understanding DSOMM’s Key Components

DSOMM Dimensions

DSOMM categorizes security practices into five main dimensions:

1. Build and Deployment: This dimension focuses on practices related to software deployment and build processes, ensuring they are secure by design. It includes areas like continuous integration, deployment security, and configuration management.
2. Implementation: Focuses on integrating security practices into the actual implementation of systems and applications. This includes secure coding standards, frameworks, and guidelines to reduce vulnerabilities introduced during development.
3. Culture and Organization: This area emphasizes the importance of security culture within an organization. It covers training, project management, and organizational structures that support security as an integral part of the development lifecycle.
4. Information Gathering:  Involves collecting data related to potential vulnerabilities, emerging threats, and best practices. This dimension helps teams stay informed and make data-driven decisions to protect their systems against evolving security challenges.
5. Test and Verification: This dimension deals with the methods and practices for testing and verifying the security of applications. It includes static and dynamic analysis, penetration testing, and security testing within the CI/CD pipeline.

DSOMM Maturity Levels

Each dimension in DSOMM is further divided into specific activities, or in DSOMM terminology–– sub-dimensions, that are spread across five maturity levels:

1. Level 1 (Initial): At this level, organizations begin to implement basic security practices but these are often ad hoc and not well-integrated into broader processes.
2. Level 2 (Managed): Security practices become more defined and are managed more systematically. At this stage, organizations begin to track and measure their security processes.
3. Level 3 (Defined): Security processes are well-documented and standardized across projects. There's a higher degree of automation and integration within the overall DevOps workflows.
4. Level 4 (Quantitatively Managed): At the nearly highest level, security processes are fully integrated, and performance is managed through quantitative measurements. Organizations at this level continuously optimize their security practices based on detailed analytics.
5. Level 5 (Advanced): This level was added recently, and is aligned with industry advancements. At this level, organizations implement advanced security practices at scale.

Operationalizing DSOMM - From Theory to Enforcement

When we think about how DSOMM works and how to take it from a useful framework on paper to actually implemented in our systems, it begins with four critical steps:

1. Initial Assessment and Gap Analysis: Understanding the current security practices and identifying areas for improvement.
2. Strategic Implementation of Tools: Integrating tools like Trivy, Gosec, or Semgrep to automate and enhance security checks throughout the software development lifecycle - based on the “needs” identified in the gap analysis.
3. Testing and Validation: Testing the tools implemented by defining and enforcing quality gates that validate the chosen security controls.
4. Continuous Improvement and Monitoring: Regularly revisiting and refining the security measures to keep up with evolving security landscapes and project needs.

Practical Examples of DSOMM in Action

Let’s take the security practice of Application Hardening (sub-dimension of Implementation), as an example for how to operationalize DSOMM. At the first level of maturity, we focus on explicitly considering security during the software requirements process, and how high level application security objectives (like application hardening) are mapped to functional requirements.  This means identifying the:

• Risk

• Security requirements

• Security tools, and then

• Testing the implementation against these functional requirements

So for example, if as the first phase of application hardening at maturity level 1, we’ve identified the risk as ensuring our data cannot be hijacked or stolen, and the security requirement would be to prevent our application data or code from being stolen or hijacked.  This would map to the security controls and practices of scanning code for vulnerabilities and hard-coded secrets.

Now that we have our action items, we need to implement the matching tools––these would include tools for secret scanning, code scanning (SAST), third-party dependency scanning (SCA).  Once we have implemented these security controls, we need to test them to see that they are actually working as intended.  This can be done with any number of intentionally vulnerable repositories like GOAT repositories (also maintained by OWASP for a diversity of languages and platforms), that exist for the purpose of testing, skilling up, and leveling up application security, among other industry tools that help validate security controls.

This is just one example of maturity level 1, but as you progress in the dimensions and maturity levels, the security requirements will map to unique and specific business and application logic, and higher levels will demand this level of maturity from third-party software in your supply chain as well.  And in this way, you can continuously level up your security practices with a methodical and systematic approach that is also measurable, which helps to understand progress and communicate this incremental progress to C-Levels and stakeholders.

Bringing It All Together

Security Maturity Models, particularly DSOMM, provide a robust framework for enhancing security in a structured yet flexible manner. They allow for significant strides in securing applications and protecting data while maintaining—or even accelerating—development velocity.

Implementing DSOMM isn't just about following a set of instructions—it's about adapting its principles to fit the unique needs of your organization. It requires commitment across all levels of the organization and a clear strategy for integrating tools and practices into the daily workflow. For those interested in taking their security practices to the next level, leveraging DSOMM with the support of tools like those offered out of the box by Jit can provide a comprehensive pathway to enhanced security and efficiency.