DevOps Maturity Specification
Summary
What is the DevOps Maturity Specification?
The DevOps Maturity Specification is a set of guidelines and criteria designed to help organizations assess and improve their DevOps practices. It provides a structured approach to evaluate key areas such as Basics, Quality, Security, Supply Chain Security, Analysis, and Reporting. The specification is intended to align with best practices and provide a framework for continuous improvement within the DevOps community.
Note: DevOps Maturity is a broad DevOps baseline assessment, not a replacement for specialized standards like SLSA (supply-chain integrity) or OpenSSF Scorecard (open-source security health). For supply-chain-specific criteria, see the SLSA mapping.
Key Points
- Purpose: Help organizations and teams assess DevOps practices, align on best practices, and drive continuous improvement.
- Scope: Covers key DevOps domains including build, testing, security, supply chain, analysis, and reporting.
- Maturity Levels: Tracks progress with clear visual badges (See Badge Levels) to provide an easy and intuitive overview.
- Scoring: Criteria are weighted as MUST (🟢) or NICE (🟡) enabling clear and actionable evaluation.
- Tooling: Works with devops-maturity to automate scoring via Web UI or CLI.
How DevOps Maturity Compares
DevOps Maturity is a breadth-first, automatable baseline for the whole delivery lifecycle. Most adjacent frameworks go deeper but narrower, or measure outcomes rather than practices in place. They are complements, not competitors.
| Framework | Primary focus | Scope | How you run it | Best for |
|---|---|---|---|---|
| DevOps Maturity | DevOps practices & controls in place | Build, quality, security, supply chain, analysis, reporting | CLI · Web UI · GitHub Action · YAML · AI auto-assess | A fast, broad baseline + shareable badge for OSS and internal repos |
| DORA metrics | Delivery outcomes | Deploy frequency, lead time, MTTR, change-fail rate | Telemetry from your pipeline | Measuring delivery performance once practices exist |
| OpenSSF Scorecard | OSS security health | Repo-level security heuristics | Automated checks | Hardening the security posture of a public repo |
| OpenSSF Best Practices | OSS best-practice badge | Whole SDLC, security-leaning | Web SaaS self-attestation | Earning a recognized OSS badge (SaaS only) |
| SLSA | Supply-chain integrity | Build/source provenance & attestation | Attestation + verification | Deep, verifiable supply-chain assurance |
| Traditional maturity models (CMMI-style) | Org process maturity | Broad, process-heavy | Consultant-led assessment | Large-scale, audited process programs |
What makes it different
- Breadth, not just security — covers testing, quality, analysis, and reporting, not only supply-chain/security.
- Automatable end-to-end — machine-readable YAML in, JSON/badge out; drop the GitHub Action into CI and the badge stays current on every change.
- AI-powered auto-assessment — point it at a repo and an LLM infers the answers from README, CI config, and the file tree — no questionnaire required.
- Yours to run — CLI or self-hostable web UI; works on private/internal repos, not just public OSS, with no SaaS lock-in.
When to use which
- Start with DevOps Maturity for a quick, broad health check and a badge.
- Add DORA to track delivery outcomes over time.
- Layer OpenSSF Scorecard / SLSA for deeper security and supply-chain rigor once the D3xx/D4xx gaps are closed.
Specification
| Category | Code1 | Criteria2 | Req.3 |
|---|---|---|---|
| Basics | D101 | Branch Builds | 🟢 |
| D102 | Pull Request Builds | 🟢 | |
| D103 | Clean Build Environments | 🟡 | |
| Quality | D201 | Unit Testing | 🟢 |
| D202 | Functional Testing | 🟢 | |
| D203 | Performance Testing | 🟡 | |
| D204 | Code Coverage | 🟡 | |
| D205 | Accessibility Testing | 🟡 | |
| Security | D301 | Vulnerability Scanning | 🟢 |
| D302 | License Scanning | 🟡 | |
| Supply Chain Security | D401 | Documented Build Process | 🟢 |
| D402 | CI/CD as Code | 🟢 | |
| D403 | Artifact Signing | 🟡 | |
| D404 | Dependency Pinning | 🟡 | |
| D405 | SBOM Generation | 🟡 | |
| Analysis | D501 | Static Code Analysis | 🟡 |
| D502 | Dynamic Code Analysis | 🟡 | |
| D503 | Code Linting | 🟡 | |
| Reporting | D601 | Notifications & Alerts | 🟢 |
| D602 | Attached Reports | 🟡 | |
| D603 | Compliance Mapping & Auditability | 🟡 |
Proposed a new criteria? Please open an issue.
Badge Levels
Your score will generate one of the following badges:
| Level | Score Range | Badge |
|---|---|---|
| WIP | 0 - 29 |  |
| PASSING | 30 - 49 |  |
| BRONZE | 50 - 69 |  |
| SILVER | 70 - 89 |  |
| GOLD | 90 - 100 |  |
Criteria Reference
Code Map
| Code | Description |
|---|---|
| D1xx | Basics |
| D2xx | Quality |
| D3xx | Security |
| D4xx | Supply Chain Security |
| D5xx | Analysis |
| D6xx | Reporting |
- All criteria codes are prefixed by domain letter (e.g.,
Dfor DevOps) - Code format:
DXYZD= Domain (DevOps)X= Category (e.g., 1: Basics, 2: Quality)YZ= Criteria number
Criteria Details
Click to expand criteria details
| Code | Criteria | Description |
|---|---|---|
| D101 | Branch Builds | Enables builds to be triggered from any Git branch, not limited to the main or default branch. |
| D102 | Pull Request Builds | Supports automatic builds for pull requests (PRs), allowing validation before merging into target branches. |
| D103 | Clean Build Environments | Ensures builds run in isolated, reproducible environments (e.g., containers or virtual machines) to avoid contamination from previous runs. |
| D201 | Unit Testing | Supports execution of unit or component-level tests to validate individual functions or modules in isolation. |
| D202 | Functional Testing | Enables running functional, integration, or end-to-end (E2E) tests to validate system behavior and interactions. |
| D203 | Performance Testing | Supports performance-related testing, such as load, stress, and scalability tests, to evaluate system responsiveness and stability under pressure. |
| D204 | Code Coverage | Enables measurement of test coverage, including metrics like line, branch, and function coverage, to assess test effectiveness. |
| D205 | Accessibility Testing | Supports testing for compliance with accessibility standards (e.g., WCAG) to ensure usability for people with disabilities. |
| D301 | Vulnerability Scanning | Scanning source code, containers, or infrastructure for known security vulnerabilities using tools like Snyk, Trivy, or SonarQube security rules. |
| D302 | License Scanning | Checking open-source dependencies for license compliance and legal risks to avoid unapproved or incompatible usage. |
| D401 | Documented Build Process | CI/CD build steps are version-controlled and documented. |
| D402 | CI/CD as Code | Pipelines and infrastructure are defined as code (IaC, PaC). |
| D403 | Artifact Signing | Build artifacts are cryptographically signed. |
| D404 | Dependency Pinning | All dependencies are pinned to exact versions. |
| D405 | SBOM Generation | Automatically generate and manage Software Bill of Materials (SBOMs) using SPDX or CycloneDX. |
| D501 | Static Code Analysis | Analyzing code without executing it to detect bugs, code smells, or potential security issues. |
| D502 | Dynamic Code Analysis | Analyzing running applications to detect runtime vulnerabilities, memory leaks, or behavioral issues. |
| D503 | Code Linting | Checking code for style, formatting, and consistency rules. |
| D601 | Notifications & Alerts | Notify stakeholders on key CI/CD events. |
| D602 | Attached Reports | CI/CD runs produce and attach structured test and analysis reports. |
| D603 | Compliance Mapping & Auditability | Map controls to standards (e.g., SLSA, NIST, ISO 20243) and provide audit-ready reports. |
FAQ
What is the difference between OpenSSF Best Practices and DevOps Maturity?
OpenSSF Best Practices targets open source projects across the entire software development lifecycle, while DevOps Maturity focuses specifically on DevOps practices applicable to both open source and internal enterprise projects. DevOps Maturity provides both a web UI and a CLI for automatic maturity scoring. In contrast, OpenSSF Best Practices only offers a web-based SaaS and does not support internal deployment.
How does DevOps Maturity relate to DORA metrics?
They answer different questions. DORA metrics measure delivery outcomes — how fast and how reliably you ship (deployment frequency, lead time, change-failure rate, time to restore). DevOps Maturity measures whether the practices and controls that produce those outcomes are actually in place. Use DevOps Maturity to find and close practice gaps, and DORA to track the performance results over time. They work well side by side.
How does DevOps Maturity relate to OpenSSF Scorecard?
OpenSSF Scorecard runs automated security-health checks on a repository and is focused on open-source security. DevOps Maturity is broader — it also covers testing, quality, analysis, and reporting — and works for internal/private projects, not only public OSS. Scorecard is a great way to deepen the security (D3xx) and supply-chain (D4xx) dimensions once a baseline is established.
How does DevOps Maturity relate to SLSA?
DevOps Maturity does not replace SLSA — it complements it. SLSA is a specialized supply-chain integrity framework with rigorous attestation formats and verification rules. DevOps Maturity covers a wider surface: build, test, quality, security scanning, supply chain, analysis, and reporting. The supply-chain criteria (D4xx) map naturally to SLSA requirements, and teams can use DevOps Maturity as a first-step health check before pursuing deeper SLSA compliance. See the SLSA mapping for details.
What is the difference between DevOps Maturity Model and DevOps Maturity Specification?
The DevOps Maturity Model is a conceptual framework that outlines the stages of DevOps adoption and maturity, while the DevOps Maturity Specification provides a detailed, actionable set of criteria and guidelines for assessing and improving DevOps practices.
How can I contribute to the DevOps Maturity Specification?
You can contribute by proposing new criteria, features, or reporting bugs. Please open an issue or create a pull request on GitHub. We welcome contributions from the community!
How can I use the DevOps Maturity Specification in my organization?
You can integrate the DevOps Maturity Specification into your organization’s DevOps practices by:
- Using the criteria to assess your current DevOps maturity level.
- Implementing the recommended criteria to improve your DevOps processes.
- Utilizing tools like devops-maturity to calculate maturity scores and generate badges automatically.
-
A criteria ID code is a unique identifier assigned to specific criteria. For more details, see the Code Map. ↩︎
-
Detailed information on each criteria can be found in the Criteria Details section. ↩︎
-
Required Levels: 🟢 Must-Have (Weight: 1), 🟡 Nice-to-Have (Weight: 0.5). ↩︎