OWASP DSOMM (DevSecOps Maturity Model) is the open framework that describes, activity by activity, what an organisation does about security in its DevOps chain, and at what maturity level. This lesson derives from it a self-assessment grid to complete in half a day, scored out of 168 points, then a prioritised action plan. It is for the CISO, tech lead or DevSecOps engineer who must establish a baseline before investing.
The model's figures were taken on 1 October 2026 from its official data, in version 5.1.0: six dimensions, including an Agentic AI dimension added in August 2026, 24 sub-dimensions, 251 activities spread over five levels. The lesson's grid keeps the five historical dimensions; for a more generic model, see DevSecOps maturity and roadmap.
What you will learn
- Understand the OWASP DSOMM model, its dimensions and its five levels
- Score your DevSecOps practices objectively from 0 to 4 on each dimension
- Interpret your overall score and identify the imbalances between dimensions
- Prioritise your actions by effort/impact ratio (quick wins, foundations, optimisation)
- Build a realistic transformation roadmap over 12 to 18 months
Prerequisites
Before going through the grid, make sure you share a common vocabulary with your team. A maturity audit loses its value if each participant has a different definition of DevOps or DevSecOps: the scores become subjective and incomparable from one session to the next. These two pages lay the foundations before scoring your practices.
- DevOps culture: the fundamental principles before talking about security.
- Introduction to DevSecOps: the overall framework and the objectives of the transformation.
Why assess your maturity?
Before launching a DevSecOps transformation, you need to know where you are starting from. Many organisations buy tools, hire and train without having established a baseline (a measured reference state): it is then impossible to measure progress, and without measurement, impossible to justify the investments to management.
The assessment answers three questions. Where are we? The deliverable is a score per dimension, which shows strengths and weaknesses. Where do we start? The deliverable is a prioritised roadmap, which puts first the actions with the best impact/effort ratio. Are we progressing? The deliverable is the delta between two assessments, tangible evidence of the return on investment.
The OWASP DSOMM model
The OWASP DevSecOps Maturity Model is a community project of the OWASP foundation. Its data is published in an open repository and served by the web tool dsomm.owasp.org, which lets you tick the activities already in place. It is concrete: each activity describes a verifiable practice, such as an automated dependency scan or centralised secrets management.
The model organises these activities into dimensions, themselves split into
sub-dimensions. The table gives the structure of version 5.1.0, taken
from the generated/model.yaml file of the
devsecopsmaturitymodel/DevSecOps-MaturityModel-data repository.
| Dimension | Sub-dimensions | Activities |
|---|---|---|
| Build and Deployment | Build, Deployment, Patch Management | 29 |
| Culture and Organization | Design, Education and Guidance, Process | 28 |
| Implementation | Application Hardening, Development and Source Control, Identity and Access Management, Infrastructure Hardening | 55 |
| Information Gathering | Logging, Monitoring, Test KPI | 31 |
| Test and Verification | Application tests, Consolidation, Dynamic and Static depth (applications, infrastructure), Test Intensity | 68 |
| Agentic AI (since 5.0.0) | Data Protection, Guidance, Isolation, Verification | 40 |
The 5 dimensions kept by the grid
Each dimension covers a different aspect, and they are not independent: the best scanning tools (Build and Deployment) are useless if nobody is trained to read their results (Culture and Organization). The grid keeps the five historical dimensions; the Agentic AI dimension concerns teams that deploy AI agents.
The first dimension, Build and Deployment, assesses the security of your CI/CD pipeline. It is the technical core of the DevSecOps transformation: how code is built, tested and deployed. The practices assessed include automated code scanning (SAST), dependency analysis (SCA), SBOM generation, artifact signing and secrets management. An organisation that is mature on this dimension has a pipeline that detects vulnerabilities before they reach production.
The second dimension, Culture and Organization, measures the cultural transformation. Tools are not enough if teams are not engaged. This dimension assesses the existence of a Security Champions programme, developer training, the clarity of shared responsibilities and management sponsorship. It is often the hardest dimension to improve because it touches human behaviour, but it is also the one with the most long-term impact.
The third dimension, Implementation, covers day-to-day development practices. How do developers write secure code? Do guidelines exist? Do code reviews include a security angle? Is threat modelling (the exercise of identifying possible attack scenarios before even writing the code) practised on new projects? This dimension assesses what happens before the code enters the pipeline.
The fourth dimension, Information Gathering, concerns the collection of security data. Do you have an inventory of your assets? Are logs centralised? Are vulnerabilities tracked in a dashboard? Are the DORA metrics measured? A mature organisation knows at any time which vulnerabilities exist, for how long, and how critical they are.
Finally, the fifth dimension, Test and Verification, assesses your validation capabilities. Beyond SAST and SCA (covered in Build and Deployment), this dimension includes dynamic tests (DAST), fuzzing, regular pentests and bug bounty programmes. It is the last line of defence before production.
DSOMM maturity levels
DSOMM defines five levels, which measure the degree of adoption of security practices, not tooling. Moving from one level to the next mostly requires a change of posture: a level 1 activity assumes a basic understanding, a level 5 activity an organisation that applies it at scale.
The official titles in the model are: Level 1 "Basic understanding of security practices", Level 2 "Adoption of basic security practices", Level 3 "High adoption of security practices", Level 4 "Very high adoption of security practices" and Level 5 "Advanced deployment of security practices at scale". Of the 211 activities of the five historical dimensions, most sit at levels 2 and 3.
The lesson's grid translates these levels into four score tiers, a convention specific to this page: Initial (reactive, ad hoc practices), Managed (practices documented on a few projects), Defined (practices standardised on more than 75% of projects) and Optimized (practices measured and continuously improved). These names echo those of models such as CMMI; they are not DSOMM's.
Self-assessment grid
Now that you understand the model, let us move on to the concrete assessment. For each practice listed in the following sections, you will give a score from 0 to 4 according to its level of implementation in your organisation. The key is to be honest: overestimating your maturity will only delay the real improvements.
A score of 0 means the practice does not exist at all; you have not even started thinking about it. A score of 1 corresponds to a pilot: the practice is being tested on 1 or 2 projects, under 25% coverage. A score of 2 indicates a partial implementation: between 25% and 75% of projects are covered, but it is not generalised. A score of 3 represents a standardised practice: documented and applied on more than 75% of projects. Finally, a score of 4 means the practice is optimised: actively measured and continuously improved.
Dimension 1: Build and Deployment
This dimension is often the easiest to assess because it covers objective technical elements: either you have a SAST scan or you do not. Take the time to check each practice in your real pipelines, not in the theoretical documentation.
For each practice, tick the level that matches your current situation:
| # | Practice | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 1.1 | CI/CD pipelines defined as code (GitLab CI, GitHub Actions...) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.2 | Automated code vulnerability scanning (SAST) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.3 | Automated dependency analysis (SCA) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.4 | Container image scanning | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.5 | Infrastructure as Code scanning | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.6 | SBOM generation for all artifacts | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.7 | Artifact signing (images, binaries) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.8 | Centralised secrets management (vault) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.9 | Ephemeral environments for tests | ☐ | ☐ | ☐ | ☐ | ☐ |
| 1.10 | Immutable deployments | ☐ | ☐ | ☐ | ☐ | ☐ |
Maximum score: 40 points
Once the boxes are ticked, add up your points for this dimension. Your score tells you where to focus your efforts:
Score below 10 points: you are at the start of the road. The fundamentals are not in place. The good news is that quick wins are plentiful. Start by defining your pipelines as code if you have not done so yet; it is the prerequisite for everything else. Then add an SCA scan (Trivy or Grype are free and easy to integrate) and centralise your secrets with a solution such as HashiCorp Vault, or even SOPS to begin with.
Score between 10 and 25 points: you have foundations, but industrialisation is missing. This is the time to add automated SAST on every PR (Semgrep is an excellent open source choice), to scan your Infrastructure as Code with Checkov, and to start generating SBOMs with Syft. The goal is to move from "a few projects covered" to "all projects covered".
Score above 25 points: your fundamentals are solid. You can now aim for excellence with artifact signing (Cosign), ephemeral environments and immutable deployments. These practices require more investment but bring a significant level of supply chain security.
On the site, static analysis is covered by the SAST guide, dependencies by SCA, the component inventory by the SBOM and centralised secrets management by HashiCorp Vault (in French): four DSOMM activities of this dimension, each with its reference tool.
Dimension 2: Culture and Organization
This dimension is more subjective than the previous one. A "Security Champions programme" can mean many different things depending on the organisation. Be rigorous in your assessment: a champion who is named but never trained and has no allocated time is not really a champion.
| # | Practice | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 2.1 | Explicit management sponsorship for security | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.2 | Active Security Champions programme | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.3 | Regular security training for developers | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.4 | Documented shared responsibilities (RACI matrix) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.5 | Retrospectives including a security angle | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.6 | Formalised Dev / Sec / Ops collaboration | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.7 | Documented and accessible security standards | ☐ | ☐ | ☐ | ☐ | ☐ |
| 2.8 | Documented and tracked exception process | ☐ | ☐ | ☐ | ☐ | ☐ |
Maximum score: 32 points
Score below 8 points: security is not yet anchored in the culture. This is often the case in organisations where security is seen as the responsibility of a dedicated team rather than a shared responsibility. The absolute priority is to get a sponsor on the executive committee; without management support, security initiatives run out of steam. In parallel, identify 1 or 2 Security Champions per team: volunteer developers who will act as relays.
Score between 8 and 20 points: the foundations exist but lack structure. You probably have champions who are named but not trained, or one-off rather than regular training. The effort must go into formalisation: documenting the standards, creating a structured training programme (not just a one-shot), integrating security into sprint retrospectives. The exception process is often neglected at this stage, yet it is crucial to avoid "shadow IT" where teams bypass the rules without documenting it.
Score above 20 points: your security culture is solid. The challenge now is continuous improvement: measuring the effectiveness of training, evolving the role of the champions, documenting lessons learned. Organisations at this level often start sharing their practices externally (conferences, blog posts), which strengthens team engagement.
To progress on this dimension, see the Security Champions programme, team training (in French) and shared responsibility: these are the human levers that raise the levels of the culture.
Dimension 3: Implementation
This dimension assesses what happens before the code enters the pipeline. The best automated protections in the world do not make up for code that was badly designed from the start. Threat modelling, secure coding guidelines and pre-commit hooks are investments that pay off in the long term.
| # | Practice | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 3.1 | Documented secure coding guidelines | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.2 | Code review systematically including security | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.3 | Pre-commit hooks (secret detection, linting) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.4 | Dependency management with lock files | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.5 | Regular and automated dependency updates | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.6 | Threat modelling for new projects | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.7 | Systematic validation of user inputs | ☐ | ☐ | ☐ | ☐ | ☐ |
| 3.8 | Secure error handling (no sensitive information) | ☐ | ☐ | ☐ | ☐ | ☐ |
Maximum score: 32 points
Score below 8 points: developers code without a safety net. Start with the practices that are easiest to adopt: install pre-commit hooks with Gitleaks to detect secrets before the commit, pin all dependencies with lock files, and enable Dependabot or Renovate to automate updates. These actions do not radically change development habits but create a first layer of protection.
Score between 8 and 20 points: you have the basics but not the systematisation. The effort must go along two axes: formalising secure coding guidelines (they often exist in the heads of the seniors but not on paper), and integrating security into code reviews. For the latter, a simple checklist is enough at first. Threat modelling on critical projects is also an excellent investment: 2-3 hours at the start of a project can avoid weeks of remediation later.
Score above 20 points: your development practices include security. You can now refine: make threat modelling systematic with a methodology such as STRIDE or PASTA, improve the quality of code reviews with decision-support tools, train teams in the secure coding patterns specific to your technologies.
The Gitleaks guide for secrets in the code, threats and risks for risk analysis, and the OWASP Top 10 CI/CD (in French) for threats specific to pipelines cover the activities of this dimension.
Dimension 4: Information Gathering
This dimension is often the most neglected. Organisations invest in detection tools but not in observability. Result: they detect vulnerabilities but do not know which ones to prioritise, do not measure their fix time, and cannot show their progress.
| # | Practice | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 4.1 | Up-to-date asset inventory (CMDB) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.2 | Centralised security logs | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.3 | Automated alerting on security events | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.4 | Centralised vulnerability dashboard | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.5 | DORA metrics collected and tracked | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.6 | Security metrics (MTTD, MTTR) measured | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.7 | Vulnerability watch (critical CVE feeds) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 4.8 | Integrated threat intelligence | ☐ | ☐ | ☐ | ☐ | ☐ |
Maximum score: 32 points
Score below 8 points: you are flying blind. You may detect vulnerabilities but you do not know how many, since when, or which ones are critical. The priority is to centralise logs (Loki or Elastic in open source) and to create a simple vulnerability dashboard. Subscribe to the critical CVE feeds of your main technologies; it is free and takes 5 minutes.
Score between 8 and 20 points: you have visibility but no metrics. This is the time to implement the DORA metrics, five since the 2024 report (change lead time, deployment frequency, failed deployment recovery time, change fail rate and rework rate), and their security equivalents (Mean Time To Detect, Mean Time To Remediate). These metrics are essential to show management the value of your security investments. The details of these indicators and their recent evolution are covered on our dedicated page on DORA metrics.
Score above 20 points: you have excellent observability. The next step is integrating threat intelligence: cross-referencing your vulnerabilities with active threats to prioritise intelligently. The most mature organisations at this level also use AI to detect abnormal patterns.
DORA metrics and their implementation (in French) give the delivery indicators, and understanding CVEs teaches you to read CVSS and EPSS to prioritise the vulnerabilities you collect.
Dimension 5: Test and Verification
This dimension complements the Build and Deployment dimension by adding the more advanced tests: DAST, fuzzing, pentests and bug bounty. It is the last line of defence before production.
| # | Practice | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|---|
| 5.1 | Security unit tests in CI | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.2 | Automated SAST on every PR | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.3 | Automated DAST in a test environment | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.4 | Automated SCA with blocking alerts | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.5 | Fuzzing on critical components | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.6 | Regular pentests (at least annual) | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.7 | Active bug bounty programme | ☐ | ☐ | ☐ | ☐ | ☐ |
| 5.8 | Systematic validation of remediations | ☐ | ☐ | ☐ | ☐ | ☐ |
Maximum score: 32 points
Score below 8 points: you have no automated safety net. The priority is to add automated SCA (Trivy is the simplest to integrate) and SAST on PRs (Semgrep offers excellent value to start with). Also schedule an annual pentest on your critical applications; it is often a regulatory or contractual requirement.
Score between 8 and 20 points: you have the basic tests but not the advanced ones. Add automated DAST (ZAP or Nuclei) to complement SAST. Fuzzing is an excellent investment for critical APIs. If you do not yet have regular pentests, move to a quarterly rhythm on exposed applications.
Score above 20 points: your tests are mature. Bug bounty is the next level: it brings an external and continuous perspective that one-off pentests cannot offer. Start with a private programme with a few trusted researchers before going public.
Automated security testing gives the overview, then DAST, Trivy and Semgrep show verification in practice: the running application, the image and its dependencies, the source code.
Calculating and interpreting your overall score
Once the 5 dimensions are assessed, you have a complete picture of your DevSecOps maturity. The overall score gives an indication of the average level, but it is above all the distribution per dimension that guides the actions: the diagram below recalls the five dimensions that make up this score, and the summary table that follows puts them side by side.
Score summary
Write your scores in the table below for an overview. The maximum score differs by dimension (40 points for Build and Deployment, 32 for the other four) because the number of practices assessed is not the same. This is why the percentage column is the only reliable basis for comparing dimensions: a raw score of 24 does not mean the same thing on a 32-point scale as on a 40-point scale.
| Dimension | Score obtained | Max score | Percentage |
|---|---|---|---|
| Build and Deployment | ___ | 40 | ___% |
| Culture and Organization | ___ | 32 | ___% |
| Implementation | ___ | 32 | ___% |
| Information Gathering | ___ | 32 | ___% |
| Test and Verification | ___ | 32 | ___% |
| TOTAL | ___ | 168 | ___% |
Interpreting the overall score
The total score gives an indication of your organisation's overall maturity tier. Keep in mind that an average can hide significant disparities: an organisation with 80% in Build and Deployment but 20% in Culture is not really at 50% maturity, it has an imbalance that limits the effectiveness of its technical investments.
A score between 0 and 40 points (Initial tier) indicates that security works in reactive mode. Practices are ad hoc, there is no defined process. The organisation discovers problems when they occur, often from external sources (audits, incidents, customers). It is the starting point of many organisations: what matters is to start structuring.
A score between 41 and 80 points (Managed tier) means that some processes are in place but not generalised. It is the stage where good practices emerge: a few projects have a secure pipeline, a few developers are trained, a few metrics are collected. The challenge now is to move from "a few" to "all".
A score between 81 and 120 points (Defined tier) represents an organisation where practices are standardised and measured. More than 75% of projects follow the same processes. The organisation is proactive: it anticipates problems rather than suffering them. It is the reasonable target for most companies.
Finally, a score between 121 and 168 points (Optimized tier) characterises an organisation in continuous improvement. Processes are regularly reviewed, decisions are driven by data, the approach becomes predictive.
Identifying action priorities
The overall score matters less than the gaps between dimensions. Visualise your results to spot the imbalances, for example with a simple progress bar per dimension:
Build and Deployment: 32/40 (80%) ████████░░Culture and Organization: 12/32 (38%) ████░░░░░░ ← PriorityImplementation: 20/32 (63%) ██████░░░░Information Gathering: 8/32 (25%) ███░░░░░░░ ← PriorityTest and Verification: 24/32 (75%) ████████░░In this example, despite a good technical score (Build and Deployment at 80%), the organisation has two major weak points: Culture and Organization and Information Gathering. Investing more in technical tools would have little impact as long as culture and observability are not strengthened.
Action plan: prioritising by ROI
Once the priorities are identified, you need to build a realistic roadmap. Not all actions are equal: some take little effort for an immediate impact, others require months of work. The key is to prioritise by effort/impact ratio, the ROI (return on investment) of each action.
Prioritisation matrix
Each action falls into one of the four categories below, from the least costly to the most ambitious. The classification gives both the sequence of launch and the horizon from which you can expect its effect.
Priority P0 (Quick wins): low effort, immediate impact. These are the actions to do in the first 2 weeks. Examples: installing pre-commit hooks, enabling Dependabot, creating a chat channel dedicated to security. These actions do not transform the organisation but create positive momentum.
Priority P1 (Foundations): medium effort, structuring impact. These actions take 1 to 3 months but build the foundations of the transformation. Examples: launching a Security Champions programme, implementing the DORA metrics, documenting the security standards. Without these foundations, technical improvements remain fragile.
Priority P2 (Optimisation): high effort, long-term impact. These actions take 3 to 6 months and require significant investment. Examples: reaching SLSA Build Level 3, integrating threat intelligence, automating threat modelling. They are only relevant once the foundations are in place.
Priority P3 (Excellence): very high effort, differentiation. These actions take 6 to 12 months and position the organisation as a reference. Examples: a public bug bounty programme, tooled anomaly detection, contributing to open source security projects.
Example of a 12-month roadmap
Here is how an organisation could structure its transformation over 12 months, starting from an initial score of 46/168. The diagram gives the four phases and the expected point gain of each, the details follow.
-
Months 1-3: Quick wins (P0)
The goal of this first phase is to create visible momentum quickly. Teams must see that something is changing, and management must see the first results.
In practice, install pre-commit hooks with Gitleaks on every repository, an action that takes a day and immediately prevents secret leaks. Enable automated SCA with Trivy on every pipeline to get immediate visibility of the CVEs in your dependencies.
Centralise secrets in HashiCorp Vault or at least in the secrets managers of your CI/CD platforms. Finally, create a simple vulnerability dashboard in Grafana or Kibana.
Expected result: +15 points, mainly on Build and Deployment.
-
Months 4-6: Cultural foundations (P1)
This phase is the most important in the long term, even if it is less visible than the previous one. Without cultural change, technical tools will be bypassed or ignored.
Identify and train one Security Champion per development team. It is not a full-time job: a few hours a week are enough. Train them together to create a community. Obtain explicit sponsorship from management: a message from the CTO or CEO on the importance of security makes a clear difference.
Document the security standards in an accessible way. An internal wiki with concrete examples is better than a 200-page document nobody reads. Also document the exception process: how can a team depart from a rule in a controlled way?
Expected result: +25 points, mainly on Culture and Organization.
-
Months 7-9: Secure pipeline (P1)
With the cultural foundations in place, technical investment makes full sense. Teams understand why these tools matter and are ready to adopt them.
Add automated SAST on every merge request with Semgrep. Scan your Infrastructure as Code with Checkov or KICS. Generate SBOMs automatically with Syft on every artifact. Integrate DAST with ZAP or Nuclei on test environments.
Expected result: +20 points, on Build and Deployment and Test and Verification.
-
Months 10-12: Excellence and supply chain (P2)
This last phase takes the organisation further, once the basic practices are mastered.
Sign every artifact with Cosign to guarantee its integrity. Aim for SLSA Build Level 2 on critical projects, a first step towards the level 3 of priority P2. Move to a quarterly rather than annual pentest rhythm. Start exploring a private bug bounty programme.
Expected result: +15 points, on Test and Verification and Build and Deployment.
Concrete scenario: a Series A startup
To illustrate the method, let us take a fictitious scenario, built for the example: a 50-person SaaS startup that has just raised its Series A. Its figures serve to show the reasoning, not to promise a result.
The context
The company develops a B2B customer data management platform. It has 8 developers, 2 ops engineers and a newly hired CISO. The investors require a SOC 2 Type II report within 18 months. The team has never done a maturity audit and does not know where to start.
SOC 2 is not a certification: it is an attestation report issued by an independent auditor according to the AICPA Trust Services Criteria. Type I describes the controls at a given date, Type II checks that they operated over an observation period of several months.
The initial assessment
The CISO carries out a first assessment with the grid. The results are no surprise, but they objectify the situation and give a numerical baseline to present to the executive committee.
| Dimension | Score | Finding |
|---|---|---|
| Build and Deployment | 12/40 | CI/CD pipeline exists but no security scan |
| Culture and Organization | 6/32 | No training, no champion, security = the CISO |
| Implementation | 14/32 | Lock files used, a few pre-commit hooks |
| Information Gathering | 4/32 | No log centralisation, no metrics |
| Test and Verification | 10/32 | One pentest last year, never followed up |
| TOTAL | 46/168 | Managed tier (low) |
This score of 46/168 places the organisation at the bottom of the Managed tier. The most critical dimension is Information Gathering (4/32): without visibility, it is impossible to steer. Culture and Organization (6/32) is the second weak point: security rests entirely on one person.
The SOC 2 action plan
The CISO presents an 18-month plan aligned with the SOC 2 objective. Each phase targets a score and some of the framework's criteria: criterion CC7.1, for example, requires detection procedures to identify newly discovered vulnerabilities.
-
Months 1-3: Technical foundations
Target score: from 46 to 76 points (+30).
The priority actions answer the SOC 2 criteria: automated SCA and SAST on every repository (vulnerability detection, CC7.1), secrets centralised in Vault (logical access management, CC6 family), two Security Champions named among the senior developers (defined responsibilities).
The CEO's sponsorship is obtained during a presentation to the executive committee where the CISO shows the gap between the current situation and the auditor's expectations.
-
Months 4-9: Culture and processes
Target score: from 76 to 101 points (+25).
A quarterly training programme is launched: 2 hours per developer, with hands-on cases on the vulnerabilities in their own code. The security standards are documented and built into onboarding.
The DORA metrics are collected automatically with Apache DevLake, Google's Four Keys project having been archived since 2024. A Grafana dashboard brings together vulnerabilities, performance metrics and incidents.
-
Months 10-14: Consolidation and Type I audit
Target score: from 101 to 121 points (+20).
SBOMs generated and stored for every artifact. Image signing with Cosign. Quarterly pentests with an external partner. A well-oiled exception process, with formal approval and tracking of exceptions.
The SOC 2 Type I audit takes place in month 14 and raises no major reservation.
-
Months 15-18: Observation period and Type II report
The following months form the Type II observation period: the team collects the evidence the auditor will examine (access logs, scan reports, fix times, exception reviews).
Scenario result: score moved from 46 to 121/168 (Optimized tier) and SOC 2 Type II report delivered in month 18.
Keys to success
Three factors make this scenario succeed. First, the clear external objective (SOC 2) aligns the whole organisation: without this deadline, the priorities would have been constantly questioned.
Second, regular assessment, every 3 months in this scenario, measures progress and adjusts the plan: if the Culture dimension progresses more slowly than expected, the actions are reinforced instead of finding out at the end.
Third, management sponsorship unlocks resources (training budget, time allocated to the champions) and sends a strong message to the teams.
Reference frameworks
DSOMM is not the only framework available. Depending on your context, other models are relevant; these references were checked at their source on 1 October 2026.
OWASP DSOMM remains the default choice for an assessment focused on the DevOps chain. It is free, maintained by an active community (version 5.1.0 of the model released on 21 September 2026), and its online tool, dsomm.owasp.org, lets you tick the activities already in place.
OWASP SAMM (Software Assurance Maturity Model), in version 2.2.0 released in July 2026, is broader than DSOMM: it covers the whole software development life cycle, organised into five business functions and fifteen security practices. It suits organisations that want a more complete view, but takes more time to administer.
BSIMM (Building Security In Maturity Model) is benchmark-oriented: it lets you compare yourself with other organisations. Its sixteenth edition, BSIMM16, released in February 2026, draws on the practices observed in 111 organisations. It mostly serves large companies that want to place themselves relative to their peers, and the assessment usually goes through a consultant.
DORA is not a security maturity model, but its performance metrics are complementary. The annual report, titled "State of AI-assisted Software Development" since 2025, has tracked five metrics since the 2024 edition: change lead time, deployment frequency, failed deployment recovery time, change fail rate and rework rate. An organisation that is mature in security but deploys only once a month has a problem: the two approaches reinforce each other.
Key points
- OWASP DSOMM 5.1.0 has six dimensions, including Agentic AI since August 2026, 24 sub-dimensions and 251 activities.
- DSOMM classifies its activities on five levels, from "Basic understanding" to "Advanced deployment at scale".
- The lesson's grid scores 0 to 4 practices of the five historical dimensions, out of 168 points, with four tiers specific to the page (Initial, Managed, Defined, Optimized).
- The overall score matters less than the gaps between dimensions: you compare percentages, not raw points.
- You prioritise by ROI: quick wins (P0), cultural foundations (P1), then optimisation (P2) and excellence (P3).
- SOC 2 is an attestation report, not a certification; Type II covers an observation period.
- DORA has tracked five metrics since 2024; Four Keys is archived, Apache DevLake takes over the collection.
- Full audit every 6 months, quick score every quarter, and technical maturity does not hold without cultural commitment.
Knowledge check
Check that you have grasped the essentials of this lesson. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: DevSecOps maturity and roadmap: a 5-level model
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
The questions below cover the most common doubts about the maturity audit: what DSOMM is, its difference with SAMM, the duration of the exercise and the score to aim for.