DevSecOps Maturity Model: A Roadmap from Security Gates to Shared Engineering Ownership

Why maturity decisions stall

Leadership conversations about a DevSecOps maturity model stall in the same place: everyone agrees security should move earlier, nobody agrees on where the organization currently sits. The usual inputs make that worse. A tool inventory tells you what was purchased. A compliance attestation tells you what was true during an audit window.

Organization-wide averages hide the thing you need to see. One product team with signed artifacts and automated policy checks pulls the average up while three other teams push to production with manual approvals and shared credentials. A useful DevSecOps assessment against a DevSecOps maturity model starts at the level of a product or a delivery system, because that's where the controls either run or don't.

How the model works

A DevSecOps maturity model describes a progression, not a grade. Capability moves from security acting as a gate at the end of delivery toward outcomes that engineering and security both measure and own. The DevSecOps maturity levels below describe what that looks like in practice.

Teams mature unevenly, and that's correct behavior. A payments service and an internal reporting tool carry different exposure, so they warrant different targets. Nathen Harvey, who leads the DORA research team at Google Cloud, made the same point about delivery performance on a DX podcast: "Context matters. Within an organization, you almost invariably have multiple applications, multiple application teams. Not every application needs to be quote unquote an 'elite performer'."

DevSecOps maturity levels

For this assessment, we use a practical four-stage model. It is not an industry standard or an official DevSecOps framework, and published models such as OWASP DSOMM (currently at v5.1.0, released September 21, 2026) define their own, more granular structures. Four practical stages are enough to place most services in a real estate of services, and each one is defined by behavior you can observe.

• Reactive and siloed. Security findings arrive late from an annual penetration test or an incident. Remediation competes with roadmap work and loses. Verizon's analysis of third-party credential reuse found a median of 94 days to remediate secrets exposed in GitHub repositories, which is roughly what this stage produces.

• Repeatable gates. Scans run on a schedule, and a security reviewer signs off before production. Coverage is real, but the control sits outside the developer's loop, so findings queue up behind the gate.

• Integrated automation. Checks run on commit and in the pipeline. Policy is code and secrets come from a managed store. Exceptions are recorded with expiry dates.

• Shared measurable ownership. Product teams own their security outcomes and have the metrics to prove it. Platform teams supply the controls as a paved road. Security sets the standard and verifies.

A particularly important transition is the one from the second stage to the third, because that’s where security stops costing delivery time. The move from the third to the fourth is organizational, and it takes longer.

Evidence beats policy claims

A policy says scanning is mandatory. Evidence says whether the job ran on the last 200 merges. Any DevSecOps assessment that accepts the first and skips the second can materially overstate maturity, and the gap shows up later as an incident nobody predicted.

What counts as evidence is narrow on purpose:

1. Repository settings: branch protection and required reviews.

2. Pipeline configuration and recent run history, including which checks are blocking and which are advisory.

3. Threat models and design review records for the services carrying the most exposure.

4. The exception register, with dates and owners.

5. Runtime telemetry and cloud posture findings pulled from the live environment.

6. Remediation data showing time to fix by severity.

Interviews still matter, but they're corroboration. Talk to a platform engineer and a product developer, because each sees a different slice of the same system. Where their accounts diverge, you've found something worth checking.

Scope scores carefully

Score the unit that owns the control. For most organizations, that's a product or a shared platform, and these rarely line up with the org chart. Aggregate afterward, with the spread visible, because an average of 3.2 across twelve services conceals the two services sitting at 1.

Pick representative systems. The team that volunteers for the assessment is the team already doing well, and scoring them first produces DevSecOps maturity levels that flatter the enterprise and mislead the board.

DevSecOps maturity model scorecard

The five groups below cover the capabilities that carry the most weight. For each capability, record the current level and the target level. Capture the evidence supporting the current score and why the gap matters in risk terms. Name the owner and state your confidence in the rating. Confidence is the field most people skip, and it's the one that keeps an unverified claim from becoming a budget line.

The four groups below cover the capabilities that carry the most weight. Keep targets honest. Not everything needs to reach the top stage.

Leadership and governance

Score culture and ownership. The signal you're looking for is shared accountability: do product teams carry security objectives, or does a central team approve their way through every release? GitLab's survey of more than 5,000 practitioners found that 58% of respondents felt some degree of responsibility for application security, which suggests the ownership shift is real but incomplete.

Risk acceptance deserves its own line. If exceptions are granted verbally and never expire, governance is weaker than the policy library, and your DevSecOps maturity levels in this group reflect that, regardless of how good the documentation looks. For regulated delivery in the Gulf, the bar is explicit, though it is worth being precise about what it covers. The Saudi Central Bank requires member organizations to operate at maturity level 3 or higher under its Cyber Security Maturity Model, where controls are defined and monitored. That is a separate scale from the stages in this article and does not mandate DevSecOps Level 3. Treat it as a reference point for governance expectations, not as a mapping.

Design and software supply

Here you score threat modeling and source control protections. Third-party code is where the backlog concentrates. Veracode reported that 70% of critical security debt originates in third-party code and the software supply chain, with library flaws averaging twelve months to remediation against eight months for first-party code.

OWASP’s 2025 Top 10 now lists Software Supply Chain Failures at A03:2025, a category that spans dependencies, CI/CD, repositories, IDEs, artifacts, and infrastructure as code. Treat it as a scoring checklist, not just a risk label. For each system, score five rows separately:

• SBOM coverage: the share of services that produce a current, accurate SBOM.

• Artifact signing and provenance: whether artifacts are signed and the build platform generates the provenance.

• Dependency governance: approved sources, version pinning, and a defined process for vulnerable or abandoned packages.

• IaC controls: review, scanning, and policy checks before infrastructure changes are applied.

• CI/CD integrity: protected pipeline definitions, least-privilege runners and tokens, and no path for unreviewed changes to reach production.

Provenance gives you a concrete ladder. The SLSA specification defines Build Level 2 as builds running on a hosted platform that generates and signs the provenance itself, and Level 3 as provenance that build steps can't forge. If you need a practice catalog underneath the scorecard, the 19 practices in NIST SP 800-218 and the dimension structure of OWASP DSOMM both map cleanly onto these rows.

Delivery infrastructure and secrets

This group covers CI/CD controls and the full secrets lifecycle. It's also where a devsecops maturity model finds its widest gap between stated and actual practice.

The numbers are not subtle. GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% jump year over year. Worse for anyone scoring rotation: 70% of the secrets leaked in 2022 were still valid when retested. Detection without revocation earns no points here.

AI-assisted development

Score whether AI coding tools sit inside your security controls or beside them. The risk is measurable: GitGuardian reports that commits co-authored by Claude Code leaked a secret 3.2% of the time, against a 1.5% baseline across public commits. The lesson is not to avoid the tools. Generated code needs the same controls as any other code, and a team’s maturity here shows in whether it can prove that.

Ask these questions for each system in scope, and ask for the artifact behind every answer:

• Approved tools: Is there a list of approved AI coding tools, and can you show which teams use anything outside it?

• Generated-code review: Is AI-assisted code reviewed under the same rules as human-written code, with a named reviewer accountable for what they approve?

• MCP configuration and secrets: Which MCP servers are permitted, who approves them, and are credentials held in a managed store instead of config files, prompts, or local environments?

• Same controls: Does AI-generated code pass the same secret scanning, dependency checks, static analysis, and policy gates as human-written code, with no bypass path?

Cloud runtime and measurement

Score cloud posture and runtime detection. Tenable's telemetry from October 2024 through March 2025 found 29% of organizations running at least one publicly exposed workload that was critically vulnerable and highly privileged at once. Over half of AWS Elastic Container Service users had a secret embedded in at least one task definition.

Measurement is the capability that makes the other four groups improvable. Without remediation timing and control coverage by service, you're re-running opinion surveys every twelve months and calling it progress.

Run a DevSecOps assessment

The fastest way to ruin this exercise is to run it like an audit. People optimize for the score, evidence gets curated, and you end up with a document nobody trusts. Run it as a joint fact-finding exercise where the output is a roadmap, and the quality of the input changes immediately.

The other failure mode is self-reporting. A DevSecOps maturity model built on questionnaires measures confidence. Ask for the artifact every time.

Set scope and evidence

Choose systems by business criticality and regulatory exposure. Four to six systems give you enough spread without a six-month engagement. Include at least one legacy service, because that's where the DevSecOps assessment will find the controls nobody has touched since the original deployment.

Collect technical evidence before the conversations, then use the conversations to explain what you found. Pull from engineering and security, and bring in operations, since each group has a partial view needed to describe how a control behaves under pressure.

Score capabilities independently

Rate each capability at the highest level fully supported by evidence, and stop there. Partial coverage is a lower level with a note. If secret scanning runs on two of nine repositories, the devsecops maturity model records two of nine.

Record variation instead of blending it away. A single enterprise number is useful for a board slide and useless for planning, because the plan has to name which service gets fixed first.

Resolve disputed scores

Security and engineering will disagree, and the disagreement is informative. Security sees the gate that was bypassed. Engineering sees the check that fires on every build but produces findings nobody can act on. Both are describing the same control from different ends.

Reconcile these in a facilitated session with the evidence on screen. Document every exception with an owner and an expiry, and flag any low-confidence finding for validation before it reaches the roadmap. A DevSecOps assessment that carries three honest "unknown" ratings beats one that carries thirty confident guesses.

Prioritize the roadmap

Turning the DevSecOps maturity model output into sequenced decisions means weighing exposure against dependency order, then implementation effort against the delivery capacity you actually have next quarter. Most organizations get the first one right and ignore the other three.

Target DevSecOps maturity levels per capability. Some rows justify the top stage for a customer-facing payments path and the middle stage everywhere else.

Start with material risk

Prioritize capabilities tied to exploitable exposure and critical assets. Verizon’s 2026 report puts exploitation of vulnerabilities at 31% of breaches as an initial access vector, ahead of credential abuse. When attackers get in through known weaknesses more often than through stolen credentials, the first question for your roadmap is what an attacker can actually reach.

Remediation speed is the other place material risk concentrates. Veracode measured the average time to fix a flaw at 252 days in 2025, up 47% over five years, while 82% of organizations now carry vulnerabilities older than a year. If your scorecard shows the same pattern, fixing throughput beats buying another scanner.

Match work to capacity

Size each initiative against what the platform team and the product teams can absorb alongside their existing commitments. A control that requires every team to build its own implementation will be adopted by the two teams with spare capacity and ignored by the rest.

Favor reusable controls. Gartner had forecast that by 2026, 80% of large software engineering organizations would establish platform engineering teams, up from 45% in 2022. That makes the platform the delivery mechanism worth using, and adoption of it is itself a maturity measure. Score paved-road adoption directly: the share of services running on the hardened pipeline template, the managed secrets backend and the standard deployment path. A reusable control gives you coverage without a mandate anyone has to police, but only on the services that use it.

Sequence enabling capabilities

Some capabilities unlock others, and getting the order wrong wastes a quarter. Service ownership and an accurate inventory come before anything that depends on routing findings to a named team. Standardized pipelines come before policy enforcement, because enforcement across twenty bespoke pipelines is twenty integrations.

Telemetry comes before automated response. Then enforcement, once the paved road exists and teams have somewhere to go when the gate closes.

Measure progress continuously

Track a small set of measures and publish them where engineering can see them: risk reduction on the exposures you prioritized and control coverage expressed as a share of services. Add the age of open exceptions and remediation time by severity. End with deployment performance and paved-road adoption. The last one predicts the others, because controls nobody adopts produce no outcomes.

Reassess on a rhythm, and on triggers. A yearly cycle for the full DevSecOps maturity model, with a lighter DevSecOps assessment each quarter for the systems that changed, keeps the picture current as architectures shift and the threat profile moves. Also reassess the affected systems after a major architecture change, an acquisition, a cloud migration, a significant security incident, or a major change to CI/CD or the platform. Each of these can invalidate the evidence behind your current scores.

What a DevSecOps maturity assessment should deliver

An assessment is only worth the engagement if it ends in decisions. At the close, you should hold:

• An evidence-based scorecard with current level, supporting evidence, and confidence for each capability

• A maturity heatmap by service, so the spread is visible and the weakest systems can’t hide behind an average

• Target levels set per capability and per system, based on exposure

• A gap and risk register that explains each gap in risk terms

• A 90-day roadmap sequenced by exposure, dependency order, and available capacity

• Owners and effort estimates for every initiative

• A KPI baseline covering coverage, remediation time, exception age, and paved-road adoption, so the next review has something to compare against

• A prioritized list of reusable platform controls, ranked by how many services each one would bring up a level

Move toward shared ownership

The shift this roadmap describes is a change in who holds the control. Late gates become automated checks inside delivery, and those checks become outcomes that product and platform teams own and measure.

ABS Technologies works with engineering leaders on cloud and DevOps delivery and on the security controls that run inside pipelines and cloud environments. To baseline your current state against a DevSecOps maturity model and build a prioritized implementation plan, contact our team.