DevSecOps maturity model: where does your team stand?
In short
A DevSecOps maturity model describes how far security is automated into development and operations. Four levels are common: manual, automatically tested, enforced in the pipeline and continuously measured. Most mid-sized companies sit between levels 1 and 2.
01
The four maturity levels
The table shows typical traits per level.
| Level | Trait | Next step |
|---|---|---|
| 1 – Manual | Security review before release, by hand | Dependency scan in every pipeline |
| 2 – Automated | SAST and dependency scans run, findings rarely fixed | Define quality gates |
| 3 – Enforced | Builds fail on critical findings, infrastructure as code checked | SBOM and signed artefacts |
| 4 – Measured | Metrics like time to remediate are managed | Continuous improvement, threat modelling |
02
Quick self-check
Do you know which open-source libraries run in production? Does a build fail on a critical vulnerability? Is your infrastructure versioned as code? Do you measure how long fixing a vulnerability takes? Every no points to the next step.
03
Assess maturity using evidence
Assess a specific product rather than assigning a single score to the entire company. Review recent releases, handled security findings and a recovery test that was actually performed.
Separate the assessment into application code, dependencies, infrastructure and operations. A well-secured repository does not compensate for missing ownership of production vulnerabilities.
- 1Choose a product and document its repository, build pipeline, artefact storage and production environment.
- 2Trace a security finding from the initial scan to verified remediation.
- 3Check that approvals and exceptions are technically traceable and assigned to an accountable person.
- 4Assess each discipline against the available evidence and explicitly record missing evidence.
- 5Derive a prioritised improvement with an owner and a verifiable completion criterion.
04
Quality gates without indiscriminate blocking
A scanner severity rating is a signal, not a complete risk assessment. Also consider reachability, exploitability, affected data and existing safeguards.
Introduce new checks in observation mode first and resolve false positives before allowing them to block releases. Exceptions need a justification, an accountable person and an expiry date.
| Finding | Possible response | Required evidence |
|---|---|---|
| Confirmed secret in the repository | Stop delivery and revoke the secret | Revocation and investigation of potential use |
| Exploitable vulnerability in an exposed service | Remediation or documented risk treatment before approval | Technical assessment and approval |
| Substantiated false positive | Narrowly scoped suppression | Reproducible justification and scheduled review |
05
Example: from finding to verified learning
Example: A team repeatedly receives findings about the same outdated library because several services include it indirectly. Instead of closing individual tickets in isolation, it updates the shared foundation and adds a regression test.
To verify progress, the team examines open risk-relevant findings, their age and recurrence of the same root cause. Compare these measures within the same product context rather than ranking teams with different risks.
06
How MAKONIS helps
MAKONIS assesses maturity in a DevSecOps assessment, builds security checks into Azure DevOps or GitHub and trains teams in its upskilling programme. On request we keep running the pipelines as managed DevSecOps.
Frequently asked questions
With clear priorities, typically three to six months per product team.
Innovation from Munich.Active worldwide.
Talk to us about your cloud, DevOps and AI initiatives — no obligation, directly with our engineers.