Key takeaways
- Most DevOps pipelines accumulate security work unevenly: a team might have excellent static analysis but no patch-management process, or strong logging but no incident-response hook.
- Risk, as stated: "An AI agent may be manipulated (e.g.
- Run the self-assessment against your actual pipeline, not your target state.
OWASP DSOMM (the DevSecOps Maturity Model) is a free, self-assessment framework that scores an organisation's actual security practices across 6 dimensions, roughly 20 sub-dimensions and 252 individual activities, each rated on a 5-level maturity scale from "basic understanding" to "advanced deployment at scale." Rather than a pass/fail checklist, a team marks which specific activities it performs — from centralised build logging to sandboxing AI coding agents — and gets back a heatmap of where its real security gaps sit, pulled directly from the model's own public YAML source rather than a marketing summary. The model is maintained as an OWASP community project and, as of August 2026, added a dedicated sixth dimension specifically for the security of AI-assisted development workflows.
What problem does DSOMM solve?
Most DevOps pipelines accumulate security work unevenly: a team might have excellent static analysis but no patch-management process, or strong logging but no incident-response hook. A single maturity score hides that unevenness. DSOMM's answer is to break "security maturity" into many small, independently assessable activities, organised into a matrix so a team can see exactly which areas are strong and which are still at level 1, rather than averaging everything into one misleading number. The model is designed to be tracked over time in a repository alongside the pipeline it describes — the project's own documentation recommends a "GitOps-like flow," where a team's current implementation level is itself version-controlled.
How are the 6 dimensions and their sub-dimensions organised?
Cloning the model's source repository directly for this guide confirmed the following current structure (dimension → sub-dimensions):
| Dimension | Sub-dimensions |
|---|---|
| Agentic AI (added August 2026) | Isolation · Guidance · Data Protection · Verification |
| Build and Deployment | Build · Deployment · Patch Management |
| Culture and Organization | Design · Education and Guidance · Process |
| Implementation | Application Hardening · Development and Source Control · Identity and Access Management · Infrastructure Hardening |
| Information Gathering | Logging · Monitoring · Test KPI |
| Test and Verification | Application Tests · Consolidation · Dynamic Depth for Applications · Dynamic Depth for Infrastructure · Static Depth for Applications · Static Depth for Infrastructure · Test Intensity |
Per the Culture and Organization dimension's own description in its source file, that dimension "is about enhancing the security culture within an organization," with its Design sub-dimension covering "managing architectural risks for the software solution" and Education and Guidance covering "education and guidance of all stakeholders." Each sub-dimension is a single YAML file holding the named activities that belong to it — the project's ARCHITECTURE.md states the generator "fails on duplicate uuids and duplicate activity names" and "fails on missing uuid or level," so every activity in the published model has to carry both a unique identifier and an assigned maturity level before it can ship.
What does one activity actually look like?
To make the abstract structure concrete, here is the first activity under the new Agentic AI dimension's Isolation sub-dimension, quoted directly from its source YAML:
- Activity: "Usage of sandboxing for AI agents" (level 1)
- Risk, as stated: "An AI agent may be manipulated (e.g. via prompt injection in source code, issues, dependencies or web content) or may malfunction. Without isolation, it can read secrets, modify unrelated projects, exfiltrate data or damage the developer workstation and connected systems."
- Measure, as stated: "Run AI agents and AI coding assistants with command execution capabilities in a dedicated, least-privilege sandbox (e.g. a container or virtual machine) which contains only the required project files and is destroyed after use."
- Assessment, as stated: demonstrating the sandbox configuration, a live session running inside it, that no credentials are reachable from inside the environment, and that the environment is destroyed after the task finishes.
- Cross-references: the activity maps to OWASP SAMM v2 control
I-SB-A-2and ISO/IEC 27001:2022 clause 8.31, alongside several named implementation guides.
Every one of the 252 activities this guide counted in the current model follows this same shape — a named risk, a concrete measure, and a verifiable assessment step, rather than an abstract principle.
Why does a device/firmware security site care about an "Agentic AI" dimension?
Because AI coding assistants and autonomous coding agents are now a real part of how firmware and device software gets written, and DSOMM's own maintainers added a dimension for exactly that risk rather than leaving it implicit. The Agentic AI dimension's own description states it "addresses the secure usage of AI during software development and operations, as well as the security of AI-assisted engineering workflows," and its four sub-dimensions map cleanly onto concrete engineering controls: sandboxing agent execution (Isolation), writing secure-coding rules an AI assistant must follow (Guidance), preventing an AI tool from leaking secrets or embedded keys (Data Protection), and reviewing AI-generated code and specifications before they ship (Verification). It deliberately does not duplicate existing static/dynamic testing activities already covered elsewhere in the model — a design choice the project documents explicitly to avoid double-counting.
DSOMM compared with OWASP SAMM
| OWASP DSOMM | OWASP SAMM | |
|---|---|---|
| Unit measured | Individual pipeline/tooling activities | Organisation-wide practice areas |
| Structure | 6 dimensions → ~20 sub-dimensions → 252 activities, 5 levels | 5 business functions → 15 practices → 2 streams, 3 levels |
| Typical use | Week-to-week CI/CD backlog, tracked in-repo | Periodic program self-assessment, reported to leadership |
| Format | Interactive web matrix + YAML, GitOps-trackable | Self-scoring spreadsheet/toolkit |
The two are not competitors — see OWASP SAMM: the Software Assurance Maturity Model, explained for the program-level model; a team can use SAMM to report maturity upward and DSOMM to decide what specifically to build into the pipeline next.
Where should a device or firmware team start?
Run the self-assessment against your actual pipeline, not your target stateDSOMM's heatmap is only useful if the marked activities reflect what is genuinely implemented today. Treat level 1 activities as the floor, not the goalThe model's own level-1 label is "basic understanding of security practices" — real maturity work starts once level 1 across most sub-dimensions is routine. If your team already uses AI coding assistants or agents, assess the Agentic AI dimension firstIt is the newest, least-likely-to-already-be-covered part of most pipelines' existing security posture. Re-run the assessment on a cadence, and store the result in version controlalongside the pipeline it describes, as the project itself recommends, so the trend — not a single snapshot — drives prioritisation.
Several of DSOMM's own activities (software bill of materials generation, dependency and configuration hardening, protecting build-toolchain integrity) describe exactly the checks SoftWSP's device firmware security service runs against a shipped binary — unpacking the image, building an SBOM, and flagging hard-coded keys, debug services and unsigned update mechanisms an AI-reviewed finding then has an engineer confirm. See device firmware security.
This guide is based on a direct read of the OWASP DevSecOps Maturity Model's own public source — the devsecopsmaturitymodel/DevSecOps-MaturityModel-data GitHub repository (cloned directly for this guide to confirm dimension names, sub-dimensions and the exact activity count), its ARCHITECTURE.md, meta.yaml and CHANGELOG.md, plus the project's OWASP wiki page and public site — rather than a secondary summary. Activity counts and the dimension list reflect the model as fetched for this guide and will change as the project is updated; this guide is general information, not a substitute for running the live assessment against your own pipeline.
Sources
- OWASP: DevSecOps Maturity Model (project page — license, maintainers, status)
- DSOMM live application and documentation
- GitHub: devsecopsmaturitymodel/DevSecOps-MaturityModel-data — README
- GitHub: DevSecOps-MaturityModel-data — ARCHITECTURE.md (model structure: dimension/sub-dimension/activity fields)
- GitHub: DevSecOps-MaturityModel-data — meta.yaml (maturity level labels)
- GitHub: DevSecOps-MaturityModel-data — Agentic AI dimension source (_meta.yaml, Isolation.yaml)
- GitHub: DevSecOps-MaturityModel-data — CHANGELOG.md (v5.0.0 Agentic AI release, 2026-08-18)
Frequently asked questions
What is OWASP DSOMM?
The DevSecOps Maturity Model, an OWASP project (listed on OWASP's own project page as a Lab-stage project) that lets a team self-assess and prioritise security activity across its software development and operations pipeline. Unlike a yes/no checklist, DSOMM breaks security work into a matrix of dimensions, sub-dimensions and individual activities, each assigned a maturity level from 1 to 5 — a team marks which activities it actually performs and gets back a visual heatmap of where its real gaps are. It is maintained as an OWASP community project, originally created by Timo Pagel, with the model's source data and application now hosted under the `devsecopsmaturitymodel` GitHub organisation and published at dsomm.owasp.org.
How is the DSOMM model actually structured?
As a three-level hierarchy, confirmed directly from the model's own source repository (`DevSecOps-MaturityModel-data` on GitHub): a **dimension** (a broad area, e.g. "Build and Deployment"), containing one or more **sub-dimensions** (e.g. "Build", "Deployment", "Patch Management"), each containing named **activities** (e.g. "Defined build process"). Each activity carries, per the project's own `ARCHITECTURE.md`, a unique ID, a description, a stated risk, a measure, an assessment procedure, a difficulty rating (knowledge/time/resources), a maturity level, and cross-references to standards such as OWASP SAMM v2 and ISO/IEC 27001. Cloning the data repository directly for this guide counted 252 individual activities across the current model — a living, versioned number that changes release to release, not a fixed count like a published standard's clause list.
What do DSOMM's 5 maturity levels mean?
Per the model's own `meta.yaml` configuration file, the five levels are labelled: 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." Not every sub-dimension defines all 5 levels — a level is only included where the project judges it relevant and meaningful for that specific topic, so a sub-dimension might stop at level 3 rather than force-fitting activities up to level 5.
What is DSOMM's new Agentic AI dimension, and why was it added?
A sixth dimension, added as an explicit breaking change in the data repository's v5.0.0 release on 18 August 2026 (GitHub issue/PR #80, titled simply "add agentic AI"). Per the dimension's own description in the source YAML, it "addresses the secure usage of AI during software development and operations, as well as the security of AI-assisted engineering workflows," split into four sub-dimensions: Isolation (containing AI agents and AI-generated code in restricted environments), Guidance (secure coding rules and policies for AI-assisted development), Data Protection (preventing sensitive-data leakage through AI tools, including prompt-injection-style input/output validation), and Verification (checking AI-generated specifications, plans and code — explicitly without duplicating SAST/DAST activities already covered by the Test and Verification dimension). This is a live, dated example of a widely used open security framework adding a dedicated section for AI-assisted coding risk, not a speculative or marketing claim.
How does DSOMM differ from OWASP SAMM?
Both are OWASP maturity models, but they measure different things at a different grain. OWASP SAMM scores an organisation's overall software security *program* across 5 business functions and 15 practices, each with 2 streams and 3 levels — a strategic, governance-level self-assessment. DSOMM scores the *pipeline and tooling* directly: 6 dimensions, roughly 20 sub-dimensions and (currently) 252 individual, tool- and practice-level activities across 5 levels, each with its own risk, measure and assessment text, intended to be tracked activity-by-activity in a GitOps-style workflow alongside the code it governs. A team can reasonably run both: SAMM to report program maturity upward to leadership, DSOMM to drive the week-to-week backlog of what to actually implement next in CI/CD.
Is DSOMM free to use, and is it an officially maintained standard?
Yes to free; DSOMM's own GitHub repository states the code is GNU General Public License v3 and the model content is Attribution-ShareAlike, usable by anyone at no cost via the public site or a self-hosted Docker container. On maintenance status: it is an active OWASP community (Lab) project rather than a formally ratified standard like an ISO or IEC document — the model is intentionally versioned and updated (the project's changelog shows multiple releases through 2026, including the Agentic AI addition), so a team adopting it should expect the activity set to keep evolving rather than treat any one snapshot as final.
In this cluster
