DevSecOps maturity is measured dimension by dimension on a scale of 5 levels, from 0 (Chaos) to 4 (Optimised), then turned into a roadmap: a few quick wins to build momentum, one or two structural projects to change the foundations. This lesson is for tech leads and security managers who want to prioritise their investments instead of piling up tools.
The model is an in-house diagnostic tool, not a standard: its performance benchmarks are inspired by the DORA metrics, whose 2024 report puts the best performing cluster at 5% of failed deployments and the lowest performing one at 40%. The goal is not the maximum level everywhere, but measurable progress towards your business objectives.
What you will learn
- Assess your DevSecOps maturity objectively on 6 key dimensions
- Place your organisation on the 5-level scale, from Chaos to Optimised
- Distinguish quick wins and structural projects to balance your roadmap
- Prioritise your actions by business risk rather than technical ease
- Build a realistic annual roadmap, quarter by quarter
- Avoid the classic traps that make DevSecOps transformations fail
Why assess your DevSecOps maturity?
Imagine two teams: team Alpha deploys to production several times a day with confidence, while team Beta dreads every monthly release. Both teams may well use the same tools, but their level of maturity differs radically. Understanding where you stand is the first step to progress.
Maturity assessment meets several fundamental needs. First, it objectifies the current situation by replacing subjective impressions with measurable criteria. Then, it helps prioritise investments by identifying the areas where effort will have the most impact. It also eases communication with management by providing a common language to discuss the improvements needed. Finally, it lets you measure progress over time and celebrate the wins.
Without a structured assessment, you risk working on secondary topics while essential foundations are missing. You could invest in sophisticated tools while your basic processes do not work. Assessment avoids these costly traps.
The 5-level maturity model
Unlike complex academic models, this pragmatic model in 5 levels (from 0 to 4) applies directly to your context. Each level represents a coherent step of practices that reinforce each other.
If you are looking for a more quantitative and tooled framework, the OWASP DSOMM model (DevSecOps Maturity Model) detailed in our maturity audit guide complements this approach with individually scored practices. Use this 5-level model first to place yourself quickly, then go deeper with DSOMM if you need a finer audit.
Characteristics of the Chaos level
At level 0, the organisation runs in survival mode. Deployments are rare, manual and risky. Documentation (in French) is non-existent or out of date. Every incident becomes a crisis because nobody really knows how the systems work.
Culture and organisation:
- Strong silos between Dev, Ops and Security
- Systematic blame during incidents
- No knowledge sharing
- Resistance to change
Process:
- Manual, non-reproducible deployments
- No versioning of infrastructure code
- Sporadic manual testing
- Reactive and chaotic incident management
Technology:
- Manually configured servers ("snowflakes")
- No CI/CD
- Absent or basic monitoring
- Security as an afterthought
Typical metrics:
- Lead time: weeks to months
- Deployment frequency: monthly or less
- Failure rate: > 45%
- MTTR: days to weeks
Characteristics of the Defined level
At level 1, the organisation starts to structure its practices. Processes exist and are documented, even if they are not always followed. Basic tools are in place, but their use remains inconsistent.
Culture and organisation:
- Beginning of cross-team collaboration
- Processes documented but not always followed
- Initial training in DevOps practices
- Leadership that supports the transformation
Process:
- Version control for application code
- Automated builds (basic CI)
- Identified test environments
- Documented incident procedures
Technology:
- CI server in place (Jenkins, GitLab CI...)
- Beginning of Infrastructure as Code
- Monitoring of basic system metrics
- One-off security scans
Typical metrics:
- Lead time: days to weeks
- Deployment frequency: weekly to monthly
- Failure rate: 31-45%
- MTTR: hours to days
Quick wins to reach level 2:
- Automate unit tests in CI
- Version the infrastructure configuration
- Set up alerts on critical metrics
Characteristics of the Managed level
At level 2, automation becomes the norm rather than the exception. Teams measure their performance and use this data to improve. Collaboration between Dev and Ops is effective, even if frictions remain: this is when structuring teams in clear topologies starts to pay off.
Culture and organisation:
- Emerging cross-functional teams
- Blameless postmortems practised
- Regular knowledge sharing
- Common Dev/Ops objectives
Process:
- Full CI/CD pipeline up to staging
- Automated tests (unit, integration, e2e)
- Infrastructure as Code generalised
- Structured incident process with postmortems
Technology:
- Automated deployments to staging
- Application monitoring (APM)
- Centralised logs
- Security scans integrated into CI
Typical metrics:
- Lead time: days
- Deployment frequency: daily to weekly
- Failure rate: 16-30%
- MTTR: hours
Quick wins to reach level 3:
- Implement feature flags
- Automate production deployments
- Define SLOs and track the error budget
Characteristics of the Measured level
At level 3, decisions are data-driven. The DORA metrics are tracked and used to drive continuous improvement. Security is built into the development cycle, not added afterwards, with relays such as security champions in each team.
Culture and organisation:
- Real autonomous product teams
- Culture of experimentation (fail fast, learn fast)
- Security as a shared responsibility
- Systematic continuous improvement
Process:
- Continuous deployment to production
- Canary releases or blue-green
- Occasional chaos engineering
- Security champions in each team
Technology:
- Full observability (logs, metrics, traces)
- Sophisticated feature flags
- Centralised secrets management
- Automated SAST/DAST/SCA
Typical metrics:
- Lead time: hours to days
- Deployment frequency: daily to several times a day
- Failure rate: < 15%
- MTTR: under an hour
Quick wins to reach level 4:
- Implement auto-remediation for common incidents
- Integrate threat modelling into design
- Set up regular game days
Characteristics of the Optimised level
At level 4, the organisation is proactive rather than reactive. Generative AI and automation tools augment human capabilities, but only when the Dev, Ops and Security foundations are already solid. The DORA 2025 report on AI in software development is clear on this point: AI amplifies what already exists. It makes a mature team even faster, but it worsens the dysfunctions of a struggling team. Security is native, built in from design. Innovation is continuous and controlled.
Culture and organisation:
- Innovation as a way of working
- Institutionalised continuous learning
- External collaboration (open source, community)
- Distributed technical leadership
Process:
- Continuous deployment with automatic validation
- Auto-remediation of common incidents
- Systematic threat modelling
- Mature platform engineering
Technology:
- AIOps for anomaly detection
- Self-healing infrastructure
- Native zero-trust security
- Optimised developer experience (IDP)
Typical metrics:
- Lead time: under an hour
- Deployment frequency: on demand
- Failure rate: < 5%
- MTTR: minutes
What the DORA 2024 measurements say
The "typical metrics" in the tabs are orders of magnitude to place yourself, not official thresholds. The most followed public reference is the DORA report (DevOps Research and Assessment), whose 2024 edition classifies teams into four performance clusters. The table reproduces their values from the summary published by Octopus Deploy.
| DORA 2024 cluster | Deployment frequency | Change lead time | Change fail rate | Failed deployment recovery time |
|---|---|---|---|---|
| Elite | On demand | Less than a day | 5% | Less than an hour |
| High | Daily to weekly | 1 day to 1 week | 20% | Less than a day |
| Medium | Weekly to monthly | 1 week to 1 month | 10% | Less than a day |
| Low | Monthly to every six months | 1 to 6 months | 40% | 1 week to 1 month |
One detail of the table is a lesson in itself: in 2024, the Medium cluster fails less often (10%) than the High cluster (20%). A single indicator is therefore not enough to rank a team; it is the combination of the four, and the same 2024 edition added a fifth metric, the rework rate, which counts the unplanned deployments made to fix an incident.
The dimensions of the assessment
A maturity assessment cannot be boiled down to an overall score. Your organisation may excel in some areas while lagging significantly in others. This is why it is essential to assess each dimension separately, then cross-check the results to get a complete picture.
Continuous integration and deployment (CI/CD)
The CI/CD dimension measures your ability to deliver code to production reliably and fast. At the lowest level, manual builds turn each deployment into a stressful surgical operation. At the highest level, every commit can potentially reach production in a few minutes, with full confidence in the process thanks to a secure pipeline.
To assess this dimension, ask yourself these questions: how long does it take between a commit and its release to production (the lead time)? How many manual interventions are needed? What percentage of deployments fail?
Testing practices
The Testing dimension reveals your safety net. Without automated tests, every code change becomes a risky bet. At the initial level, tests are manual and sporadic. At the optimised level, a complete test pyramid (unit, integration, end-to-end) automatically validates every change, complemented by automated security tests (in French), and Test-Driven Development (TDD, writing the test before the code) guides development.
Assess the percentage of code coverage, but also the quality of the tests: do they really detect regressions? How many bugs reach production despite the tests?
Built-in security
The Security dimension measures how far security practices are woven into your development cycle. In an immature organisation, security steps in at the end of the cycle, often seen as a brake. In a mature organisation, security is shift-left: built in from design, with automated scans at each stage, coverage of the OWASP Top 10 baseline and security gates that block vulnerabilities before they reach production.
Observability
Observability determines your ability to understand what is happening in your systems. At the basic level, you have a few logs on the servers. At the advanced level, you combine logs, metrics and distributed traces, with smart alerts that warn you of problems before they affect users.
Good observability answers the question: "When something goes wrong, how long does it take to understand why?"
Incident management
This dimension assesses how you respond to problems and, above all, how you learn from them. An immature organisation reacts in chaos and looks for culprits. A mature organisation follows a structured process, runs blameless postmortems (an analysis without looking for culprits), defines SLOs (Service Level Objectives) and uses incidents as opportunities for improvement.
The software supply chain
An often neglected dimension, the supply chain measures your control of dependencies and of the provenance of your code. At level zero, you have no visibility of what your applications contain, nor of the CVE management that affects them. At the highest level, you generate SBOMs (Software Bill of Materials, the inventory of all the components of an application), sign your artifacts and reach SLSA compliance levels.
Quick wins versus structural projects
Not all improvements are equal. It is crucial to distinguish two types of actions in your roadmap: quick wins and structural projects. Confusing the two leads either to frustration (waiting for quick results from a long-term project) or to stagnation (chaining quick wins without ever transforming the foundations).
Quick wins are low-effort actions that produce visible results in a few days. Enabling a basic SAST scan in your CI pipeline, creating a dashboard showing the DORA metrics, or documenting a postmortem template: these actions do not transform your organisation, but they create traction. They show that change is possible and motivate teams for bigger efforts.
Structural projects require weeks or months of effort, but they transform your capabilities for good. Overhauling a CI/CD pipeline, implementing SLSA compliance, or setting up an Internal Developer Platform: these projects require significant investment, but they raise your maturity level durably.
The winning strategy is to start with quick wins to build momentum, while planning one or two structural projects in parallel. Quick wins keep motivation up while the long-term projects progress.
Building your improvement roadmap
An effective roadmap is not a wish list. It is a sequenced plan that takes into account your constraints, your resources and the dependencies between actions. The method has six steps that form a loop: the diagram sums it up, the details follow.
-
Honest self-assessment
Start by scoring each dimension from 0 to 4 based on the characteristics described above. Involve several people to avoid bias: a developer, an ops engineer and a security manager will often see the same reality differently. The average of their perceptions is closer to the truth.
-
Identifying the critical gaps
Compare your scores with your target. If you are an e-commerce company, a level 1 in observability is probably critical because you cannot afford not to see performance problems. On the other hand, a level 2 in supply chain may be acceptable in the short term. Identify the 2 to 3 most dangerous gaps for your business.
-
Prioritisation by business risk
Rank your gaps not by technical ease, but by impact on your business. A security gap in an application handling health data is a priority. A CI/CD gap in a team that rarely deploys can wait. This prioritisation ensures that your efforts really serve the company's objectives.
-
Selecting quick wins
For each priority gap, identify at least one action achievable in under a week. These quick wins act as a "foot in the door": they prove that improvement is possible and prepare the ground for more ambitious projects.
-
Planning structural projects
Do not run more than one or two major projects in parallel, such as setting up an internal platform. Each project needs attention, resources and follow-up. Spreading your efforts over too many fronts guarantees that nothing really succeeds. Better to finish one project before starting another.
-
Quarterly measurement and adjustment
The roadmap is not set in stone. Reassess your maturity every quarter, celebrate progress, adjust priorities if the context has changed. A startup raising funds may suddenly need to speed up on security to reassure its investors.
Once this method is mastered, the Implementing DevSecOps (in French) track details how to carry out each of these steps concretely, from the first maturity audit to the good practices of implementation.
A concrete example of an annual roadmap
To illustrate this method, let us imagine a development team that starts from an overall level 1 and aims for level 3 on the most critical dimensions. Here is how it could structure its year.
The first quarter focuses on the quick wins that build visibility and confidence. The team enables a basic SAST scanner in its CI to start detecting obvious vulnerabilities (SAST, Static Application Security Testing, analyses the source code without running it). It sets up a dashboard showing the DORA metrics to objectify its performance. Finally, it creates a postmortem template and uses it for the next incident, thus starting a learning culture.
These actions take only a few days each, but they lay the foundations for everything that follows. SAST reveals the real state of code security. The DORA dashboard lets you measure future progress. The postmortem template turns incidents into opportunities.
The second quarter tackles sturdier foundations. The team deploys an SCA tool (Software Composition Analysis, the analysis of third-party libraries) to manage its vulnerabilities and know the CVEs in its third-party libraries. It defines SLOs for its most critical services, creating a common language between developers and ops about what is "acceptable". It also organises a first security training for developers, turning security into a shared responsibility rather than an external constraint.
At the end of this quarter, the team has better visibility of its risks (vulnerable dependencies), clear reliability objectives (SLOs), and developers more aware of security issues.
The third quarter aims at automation and integration. The team sets up automated security gates that block merge requests containing critical vulnerabilities. It starts generating and storing SBOMs for each release, laying the foundations of traceability. It also deploys distributed traces to complete its observability and understand performance problems in its microservice architectures.
These actions take more effort but significantly raise the maturity level. Automated gates ensure that security is no longer optional. SBOMs prepare future compliance. Traces make it possible to diagnose previously invisible problems.
The fourth quarter consolidates the gains and prepares the next level. The team implements artifact signing with Cosign, guaranteeing the integrity of what is deployed. It makes threat modelling systematic in the design of new features, anticipating security problems rather than suffering them. Finally, it runs its first chaos engineering exercises to validate the resilience of its systems.
At the end of the year, the team has gone from a chaotic level 1 to a solid level 3 on the critical dimensions. It has a secure pipeline, full observability, and a culture of continuous improvement.
Traps to avoid
The path to DevSecOps maturity is strewn with pitfalls. Well-meaning teams regularly fail not through lack of skills, but because they fall into predictable traps. Recognising these traps before falling into them can save you months of misdirected effort.
-
The first trap is the quest for perfection. Some teams aim for level 4 on one dimension before dealing with the others. Result: they excel at CI/CD but have no observability, or the other way round. A balanced maturity at level 2 on every dimension is better than an isolated level 4 surrounded by critical gaps. The dimensions reinforce each other: without observability, your sophisticated CI/CD will not tell you when it breaks something in production.
-
The second trap is blind imitation. Netflix, Google and Spotify generously share their practices, and it is tempting to copy them. But their context is not yours. What works for a streaming company with thousands of engineers does not necessarily apply to a 50-person SME. Draw on the principles, not on specific implementations.
-
The third trap is the absence of quick wins. A DevSecOps transformation takes months, even years. Without quick and visible wins, motivation fades. Teams lose confidence in the project, management grows impatient, and the initiative slowly dies. Quick wins are not wasted time: they are the fuel that keeps the transformation moving.
-
The fourth trap is dispersion. Launching five structural projects in parallel guarantees that none will really succeed. Resources are fragmented, attention is diluted, and each project progresses so slowly that nobody sees results. Focus on one or two projects at a time, finish them, then move on to the next ones.
-
The fifth trap is the one-off assessment. Measuring your maturity once and then putting the report in a drawer is useless. Your context evolves, your teams change, new threats appear. Reassess your maturity at least every quarter to adjust your roadmap and celebrate the progress made.
-
The sixth trap, more recent, is counting on AI to make up for a maturity deficit. The 2025 edition of the DORA report, "State of AI-assisted Software Development", shows that 90% of respondents use AI at work, but that these tools amplify existing dynamics rather than correcting them: an already solid team gets a real throughput gain, a disorganised team sees its instabilities worsen. An AI assistant replaces neither reliable tests, nor a stable CI, nor a postmortem culture.
Self-assessment: your starting point
Before building your roadmap, you need to know where you stand. This self-assessment guides you through the key points to check. Be honest: an optimistic assessment will not help you progress.
Start by gathering the key stakeholders: at least one representative from development, one from ops, and if possible one from security. Each one assesses independently, then you compare the results. Differences in perception are often as instructive as the scores themselves.
For each dimension, ask yourself the following questions:
CI/CD: what is your average lead time between commit and production? How many manual steps does your pipeline contain? What percentage of deployments fail and require a rollback?
Testing: what is your code coverage? Do you have automated integration tests? How many critical bugs reach production each month?
Security: are security scans integrated into CI? How long does it take to fix a critical vulnerability? Are developers trained in security good practices?
Observability: can you answer "why did this request fail?" in under 5 minutes? Are you alerted to problems before users report them?
Incidents: do you run systematic postmortems? Are corrective actions followed through to resolution? Do you have defined and measured SLOs?
Supply chain: do you know which dependencies your applications contain? Are you alerted when a CVE affects one of them? Do you sign your artifacts?
After answering honestly, give each dimension a score from 0 to 4. Your current maturity profile is the starting point of your roadmap. To formalise this follow-up over time with numerical indicators, our guide on security KPIs details the metrics to instrument, and the maturity audit guide offers a more detailed grid based on OWASP DSOMM.
Key points
This 5-level model and this roadmap method are only worthwhile if you apply them regularly rather than reading them once.
- DevSecOps maturity is measured per dimension (CI/CD, testing, security, observability, incidents, supply chain), never by a single overall score.
- The 5-level model (0 to 4) goes from manual chaos to proactive optimisation; its metrics are orders of magnitude, the numerical reference remains the DORA report.
- In 2024, the DORA Medium cluster fails less often (10%) than the High cluster (20%): a single indicator does not rank a team.
- A balanced maturity at level 2 on every dimension is better than an isolated level 4 surrounded by critical gaps.
- Quick wins create quick traction; structural projects transform your capabilities for good: a solid roadmap combines the two.
- Prioritisation by business risk, not by technical ease, ensures that your efforts really serve the company.
- Never run more than one or two major projects in parallel: dispersion is the most frequent trap of ambitious transformations.
- Reassess your maturity every quarter: the context evolves, and a frozen roadmap quickly becomes obsolete.
- Generative AI amplifies your existing maturity, it does not replace it: invest in the foundations first before expecting gains from automation.
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: Implementing DORA metrics: a practical guide for 2026
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 DevSecOps maturity: definition, self-assessment method, difference with DSOMM and building the roadmap.