OWASP DSOMM
a maturity model for the DevSecOps pipeline
OWASP DSOMM (DevSecOps Maturity Model) measures the maturity of a DevSecOps programme across four dimensions and sixteen sub-dimensions, on a four-level scale. Run DSOMM assessments as structured records, score each sub-dimension, build the pipeline improvement roadmap, and re-score over time so the maturity claim is a record rather than a one-off slide.
No credit card required. Free plan available forever.
OWASP DSOMM: a maturity model for the DevSecOps pipeline
OWASP DSOMM (DevSecOps Maturity Model) is the open framework that measures the maturity of a DevSecOps programme across four dimensions and sixteen sub-dimensions, on a four-level scale. Where OWASP SAMM measures the AppSec function at the organisational layer, DSOMM measures what the pipeline and the runtime actually do: how builds are produced, how artefacts are signed, how secrets are handled, how the runtime is hardened, and how the testing and monitoring planes operate. The two are complementary rather than competing: SAMM is the organisational maturity model the AppSec function is built against; DSOMM is the pipeline maturity model the platform and the runtime are built against.
DSOMM is most useful when an organisation needs to talk about DevSecOps in operational terms rather than aspirational ones. A statement like “we have a mature DevSecOps programme” is unfalsifiable. A statement like “Build and Deployment is at Level 3, Culture and Organization is at Level 2, Implementation is at Level 3, and Information Gathering is at Level 2, with eight sub-dimensions on a roadmap to Level 4 over the next two cycles” is operational. The DevSecOps enterprise guide covers the programme thinking behind that statement; DSOMM gives it a scorecard.
The four DSOMM dimensions and the sixteen sub-dimensions
DSOMM organises its model into four dimensions, each containing three or four sub-dimensions, for a total of sixteen sub-dimensions. Each sub-dimension carries a catalogue of activities and a per-activity maturity level. The dimensions are the unit of leadership communication; the sub-dimensions are the unit of programme planning; the activities are the unit of measurement.
Build and Deployment
Sub-dimensions: Build, Deployment, Patch Management
The pipeline integrity dimension. Build and Deployment covers reproducible builds, signed artefacts, base image management, immutable infrastructure, deployment automation, rollback safety, and the patch flow that keeps build dependencies, base images, and pipeline tooling current. This is the dimension where the pipeline either becomes a reliable security control or stays a fragile script collection. Low Build and Deployment scores read as a programme that ships code but cannot reliably reproduce what it shipped or roll back when something breaks.
Culture and Organization
Sub-dimensions: Design, Education and Guidance, Process
The people and process dimension. Culture and Organization covers threat modelling, secure design review, peer-review discipline, developer training, role guides, secure-coding reference material, ticket lifecycle, definition of done with security gates, and incident handling. This is the dimension that turns a security tool buy into a working programme. Low Culture and Organization scores read as a programme that has invested in tooling but has not turned the tooling into shared engineering practice.
Implementation
Sub-dimensions: Application Hardening, Infrastructure Hardening, Logging
The secure-by-default dimension. Implementation covers cryptographic configuration, secrets handling, hardened runtime defaults, network segmentation, host hardening, container runtime policy, security event log generation, log integrity, and retention policy. This is the dimension that captures what the running system actually does at runtime, not what the architecture diagram claims. Low Implementation scores read as a programme that documents controls but does not enforce them in production configuration.
Information Gathering
Sub-dimensions: Test and Verification, Logging, Monitoring
The visibility dimension. Information Gathering covers the testing types and cadence the programme runs across SAST, SCA, DAST, IAST, container and IaC scanning, and manual penetration testing, the security event signal the programme operates on, and the response-time discipline that turns signal into action. This is the dimension that captures what the programme can actually see. Low Information Gathering scores read as a programme that ships code into production with no continuous signal about what is going wrong.
For programmes that run authenticated DAST, SAST, and SCA as part of Information Gathering (Test and Verification) and Build and Deployment (Build) activities, the authenticated scanning and code scanning features run those tests against the same engagement record that carries the DSOMM scorecard, with repository connections binding each scan back to a specific commit on a specific branch so the activity-observed claim is backed by live pipeline output rather than a screenshot of a dashboard.
The four maturity levels: from ad hoc to continuously verified
Each of the sixteen sub-dimensions is scored on a four-level scale. Level 1 (Basic understanding of security practices), Level 2 (Adoption of basic security practices), Level 3 (High adoption of security practices), and Level 4 (Very high adoption of security practices) capture an increasingly disciplined and continuously verified pipeline posture. The progression is operational: Level 1 looks like a single individual running the practice on a manual cadence; Level 2 looks like a documented programme with a few teams adopting it; Level 3 looks like a standardised practice every team follows with regular evidence; Level 4 looks like a continuously verified practice with measurable outputs and breaking-build gates.
- Sub-dimensions are the unit of measurement; each of the sixteen sub-dimensions has a catalogue of activities and a maturity level per activity, with evidence captured at the sub-dimension level rather than the dimension level
- Dimensions roll up sub-dimensions; the four dimensions (Build and Deployment, Culture and Organization, Implementation, Information Gathering) are how DSOMM communicates the shape of the programme to leadership, with sub-dimension averages aggregated per dimension
- Each sub-dimension carries a target maturity level the programme commits to lifting against; the gap between current and target is the unit of programme planning, not the absolute level itself
- Evidence per activity is what survives turnover; each scored activity should be backed by an artefact (build script, signed artefact attestation, training record, secret store inventory, hardening checklist, scanner output, monitoring runbook) on a durable record rather than a checkbox in a spreadsheet
- Re-measurement on cadence is how the programme tracks progress; DSOMM is most useful when re-run annually with quarterly progress checks on the sub-dimensions that are actively being lifted, because pipeline maturity moves more slowly than the underlying tooling cycles
- The deliverable is the roadmap, not the scorecard; the comparative gap, the activities planned for the next cycle, and the owner per activity are what the programme actually executes against
For deeper context on the findings discipline that backs Information Gathering (Test and Verification) and Implementation (Application Hardening) activities, see the DevSecOps scanning workflow and the secret scanning remediation workflow, which together cover how scanner output becomes defensible activity-observed evidence at DSOMM measurement time.
How DSOMM sits next to OWASP SAMM, BSIMM, and NIST SSDF
DSOMM is rarely used in isolation. It is the pipeline-and-runtime measurement layer that pairs with organisational maturity models (SAMM), descriptive benchmarks (BSIMM), and regulator-facing practice catalogues (NIST SSDF). The contrast below is a working view, not a buyer comparison: the practitioner question is which frameworks to pair DSOMM with, not which to pick instead of it.
Pipeline scope vs organisational scope
DSOMM measures the DevSecOps pipeline and the runtime that it deploys to: how builds are produced, how artefacts are signed, how secrets are handled, how the runtime is hardened, and how the testing and monitoring planes operate. OWASP SAMM measures the AppSec function at the organisational layer: how the programme governs itself, designs systems, implements them, verifies them, and operates them. DSOMM and SAMM are complementary because the pipeline-and-runtime question and the organisational-function question both deserve a structured answer. Most mature programmes run DSOMM and SAMM in parallel rather than pick between them.
Four-level scale vs three-level scale
DSOMM scores on a four-level scale (Basic understanding, Adoption of basic practices, High adoption, Very high adoption). OWASP SAMM scores on a three-level scale (initial understanding and ad hoc, increased efficiency and effectiveness, comprehensive mastery at scale). The DSOMM four-level scale gives the programme a discrete step between adoption and continuous verification, which matters for pipeline practices where the difference between a scan running and a scan running continuously with breaking-build gates is operationally significant.
Maturity ladder vs descriptive benchmark
DSOMM is a prescriptive maturity ladder: it states what an organisation should do at each level for each sub-dimension. BSIMM (Building Security In Maturity Model) is a descriptive benchmark: it reports what programmes in a study population actually do. DSOMM tells the programme what good looks like; BSIMM tells the programme what peers do. The two are complementary because the question "what should we do" and the question "what do peers do" both have a role in programme planning.
Pipeline maturity vs regulator practice catalogue
DSOMM is a community-maintained pipeline maturity model. NIST SSDF (SP 800-218) is the regulator-facing practice catalogue: a list of secure-development tasks (PO, PS, PW, RV) that federal acquisition rules increasingly read against. DSOMM gives the programme a maturity ladder for the pipeline. SSDF gives the programme a practice list that satisfies the regulator. Mature programmes pair the two: DSOMM as the internal maturity model, SSDF as the regulator-facing evidence pack, with the same engagement record carrying both.
Programmes that already operate under a prescriptive secure-development standard typically pair DSOMM with BSIMM as the descriptive benchmark for activity prevalence, NIST SSDF (SP 800-218) as the regulator-facing practice list, and OWASP ASVS as the per-application verification standard. The pipeline maturity model is the operational layer; SAMM is the organisational layer; SSDF is the regulator layer; ASVS is the per-application verification layer; and the same engagement record can carry all four.
DSOMM by role: AppSec, platform engineering, CISOs, and consultancies
DSOMM reads differently depending on which side of the programme you sit on. The pipeline-and-runtime focus makes it engineering-friendly; the four-level scale makes it leadership-friendly; the activity catalogue makes it audit-friendly; the annual cadence makes it programme-friendly.
AppSec teams running DSOMM as the pipeline maturity benchmark
AppSec teams use DSOMM to position the pipeline against an explicit maturity ladder. The annual cycle is structured: score each sub-dimension against the activity catalogue, name the sub-dimensions where the programme is materially below target, plan the activity additions for the next cycle, and re-score the following year. The work product is a maturity-position document that pairs with the operational roadmap so leadership can read pipeline progress without needing to interpret raw scanner output.
Security engineering and platform teams turning DSOMM activities into pipeline work
Security engineering and platform teams translate DSOMM activity additions into actual pipeline changes: a SAST gate added to the merge pipeline, an SCA report added to the build, a base image rotation added to the patch flow, a secret store added to the deployment manifest, a structured log channel added to the runtime. The DSOMM scorecard becomes the input to the platform roadmap, not a separate compliance artefact.
CISOs and security program managers reporting on pipeline posture
CISOs and security program managers use DSOMM to report pipeline posture to the board and to executive risk committees. The reported number is the per-dimension average, the per-sub-dimension score, and the activity additions the programme has committed to. The cadence is annual with quarterly check-ins on the sub-dimensions in flight, which lines up with how board risk committees expect to consume programme progress.
Security consultancies running DSOMM assessments for clients
Security consultancies that run DSOMM assessments for clients capture the sub-dimension-by-sub-dimension scoring, the per-activity evidence, the gap analysis against target, and the recommended activity additions in a single engagement record. The client portal exposes the same record to the buyer, so the assessment is a live document the client can return to between cycles rather than a frozen PDF.
The persona-specific entry points are SecPortal for application security program leads (the canonical owner of the annual DSOMM measurement cycle and the per-sub-dimension roadmap that sits underneath it), SecPortal for DevSecOps teams, SecPortal for AppSec teams, SecPortal for security engineering teams, SecPortal for platform engineering teams, and SecPortal for CISOs. Each anchors a different view of the same DSOMM measurement record.
The annual cycle: scope, score, plan, re-measure
A DSOMM measurement is most useful when it is run as a structured annual cycle rather than a one-time engagement. The cycle has four phases: scope the sub-dimensions the programme is in scope for, score each sub-dimension against the activity catalogue with evidence per activity, plan the activity additions for the next cycle with named owners and timelines, and re-measure the following year on a comparable basis. The deliverable is not the scorecard. The deliverable is the gap between current and target maturity and the activity additions the programme commits to.
For translating activity additions into structured remediation work that supports the Information Gathering (Test and Verification) and Implementation (Application Hardening) practices, see the remediation tracking workflow, the vulnerability finding state lifecycle, and the SDLC vulnerability handoff workflow, which together cover the closure mechanics that turn a DSOMM activity addition into a sustained pipeline change rather than a checkbox.
Where SecPortal fits in a DSOMM measurement cycle
SecPortal is the operating layer for a DSOMM measurement cycle. The platform holds the scope, the per-activity evidence, the per-sub-dimension score, the per-dimension roll-up, the target level per sub-dimension, the next-cycle activity additions, and the re-measurement record on one engagement, so the measurement is a live record rather than a long email thread with attached spreadsheets. SecPortal does not ship a native DSOMM-only scoring engine; it holds the DSOMM measurement evidence on the same structured record that carries findings, retests, scanner output, AI reports, and audit evidence. For consultancies running DSOMM-style assessments on behalf of multiple clients, the security consulting workspace bundles the measurement record with branded client portals, so each client sees their own live activity catalogue and maturity position rather than a frozen PDF.
- Engagement management captures the DSOMM measurement cycle as a structured record covering the in-scope sub-dimensions, the per-activity evidence, the per-sub-dimension score, the per-dimension roll-up, the target level per sub-dimension, and the activity additions planned for the next cycle, so the measurement reads as a record rather than a slide deck
- Findings management stores the evidence that backs Information Gathering (Test and Verification) and Implementation (Application Hardening, Infrastructure Hardening) activities, with each finding carrying a CVSS 3.1 vector, a typed status across the FindingStatus enum (open, in_progress, resolved, verified, reopened, closed, false_positive), an owner-of-record, and the evidence that backs the activity score
- Code scanning runs SAST and SCA against connected GitHub, GitLab, and Bitbucket repositories under the OAuth connection, supporting Information Gathering (Test and Verification) and Build and Deployment (Build) activities on live pipeline output rather than self-reported coverage
- Authenticated scanning runs DAST behind the login screen against the same engagement record, with credentials stored encrypted at rest, supporting Information Gathering (Test and Verification) activities on a recurring schedule rather than a single annual exercise
- Repository connections under OAuth bind each scan back to a specific commit on a specific branch on a specific repository, so the Build and Deployment (Build) and Information Gathering (Test and Verification) evidence trail points at the live pipeline artefacts rather than a frozen export
- Encrypted credential storage uses AES-256-GCM at the application layer for scan credentials, supporting Implementation (Application Hardening) activities by demonstrating that the platform itself follows the secret-handling discipline it asks the programme to score against
- AI-assisted reports compose the DSOMM measurement summary, the per-dimension analysis, and the roadmap narrative from the underlying engagement record and findings, so the deliverable cites observed activities and evidence rather than starting from a blank template
- Compliance tracking lets one DSOMM measurement feed framework mappings to OWASP SAMM business functions, NIST SSDF practices (PO, PS, PW, RV), ISO 27001 Annex A.8 (technological controls), SOC 2 Common Criteria (CC7 and CC8 for change management), and PCI DSS Requirement 6 (Secure Development), so the measurement doubles as audit evidence without rebuilding the bundle per auditor
- Document management holds the DSOMM activity catalogue, the per-activity evidence references, the threat models, the training records, the secret store inventory, the hardening checklists, the test catalogue, and the monitoring runbooks, so the measurement is reproducible at the next annual cycle and defensible under audit
- Activity log records the actor, the entity, the action, and the timestamp for every measurement event, with 30, 90, and 365-day retention windows and CSV export, so the audit trail behind the DSOMM scorecard is portable across audit cycles and personnel transitions
Looking for the engagement workflow that supports the measurement record itself? The DevSecOps scanning use case and the code review use case capture how SecPortal turns Build and Deployment (Build) and Information Gathering (Test and Verification) evidence into structured records covering scope, scanner output, findings, retests, and the deliverable. For onboarding new applications into the DSOMM scope, see the security onboarding for new applications workflow.
For programme-level context on how pipeline maturity measurements fit into the wider security delivery operating model, see the security workflow orchestration research, the vulnerability management programme maturity model, and the security champions program guide, which together cover the operating-model thinking that turns a DSOMM measurement into a sustained pipeline programme rather than an annual exercise that ends with the slide deck.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Build and Deployment: the pipeline integrity dimension
The Build and Deployment dimension covers the activities that take code from a developer commit through to a hardened deployment. Sub-dimensions include Build (reproducible builds, signed artefacts, base image management), Deployment (immutable infrastructure, deployment automation, rollback safety), and Patch Management (the discipline that keeps build dependencies, base images, and pipeline tooling current). The four maturity levels run from ad hoc builds with manual deployment, through standardised pipelines with secret scanning, to fully reproducible signed builds with attested provenance and continuous patch flow. Capture per-sub-dimension scores, owners, evidence, and target levels on the engagement record so the pipeline picture is reproducible across cycles.
Culture and Organization: the people and process dimension
The Culture and Organization dimension covers the activities that turn a security tool buy into a working programme. Sub-dimensions include Design (threat modelling, secure design review, peer-review discipline), Education and Guidance (developer training, role guides, secure-coding reference material), and Process (ticket lifecycle, definition of done with security gates, incident handling). The four maturity levels run from ad hoc security review owned by a single individual, through structured developer-facing programmes with documented gates, to a continuous education programme paired with embedded security champions and a measurable process that every team follows. Score practices on the four-level scale and attach training records, threat models, and process artefacts as evidence on the same record.
Implementation: the secure-by-default dimension
The Implementation dimension covers what the running system actually does at runtime. Sub-dimensions include Application Hardening (cryptographic configuration, secrets handling, hardened runtime defaults), Infrastructure Hardening (network segmentation, host hardening, container runtime policy), and Logging (security event log generation, log integrity, retention policy). The four maturity levels run from default configuration with credentials in source, through CIS-aligned baselines with structured secret storage, to a continuously verified hardening posture with attested log integrity and runtime policy enforcement. Capture runtime configuration evidence, secrets-store inventory, and hardening checklist results on the engagement record so the Implementation score has artefacts behind it.
Information Gathering: the visibility dimension
The Information Gathering dimension covers what the programme sees. Sub-dimensions include Test and Verification (the testing types and cadence the programme runs across SAST, SCA, DAST, IAST, container and IaC scanning, and manual penetration testing), Logging (the security event signal the programme operates on), and Monitoring (the response-time discipline that turns signal into action). The four maturity levels run from ad hoc point-in-time tests, through scheduled per-pipeline scanning with consolidated dashboards, to a continuously running detection plane with structured triage and a measurable mean-time-to-detect figure. Capture the test catalogue, the scanner inventory, the log-source register, and the monitoring runbook on the engagement record so the visibility claim is auditable.
The four maturity levels and the DSOMM scorecard
Each of the sixteen sub-dimensions is scored on a four-level scale. Level 1 (Basic understanding of security practices), Level 2 (Adoption of basic security practices), Level 3 (High adoption of security practices), and Level 4 (Very high adoption of security practices) capture an increasingly disciplined and continuously verified posture. The scorecard rolls sub-dimension scores into per-dimension averages, and the overall DSOMM scorecard reports the programme position on all four dimensions, which is the unit of leadership reporting. Capture the per-activity question answers, the per-sub-dimension score, the per-dimension roll-up, and the target score per sub-dimension on the engagement record so the scorecard is reproducible at the next cycle.
Roadmap, target operating model, and DSOMM cadence
A DSOMM assessment is not the deliverable; the gap between current and target maturity is the deliverable, expressed as a roadmap that names the sub-dimensions to lift, the activities that lift them, the owner, and the timeline. The recommended cadence is annual reassessment with quarterly check-ins on the sub-dimensions that are actively being lifted, because pipeline maturity moves more slowly than the underlying tooling cycles. Track current scores, target scores, gap rationale, owner per sub-dimension, and evidence per increment on the engagement so the next cycle starts where this one left off, not from a blank slate.
How DSOMM sits next to OWASP SAMM, BSIMM, and NIST SSDF
DSOMM is not a replacement for OWASP SAMM, BSIMM, or NIST SSDF. SAMM measures the AppSec function at the organisational layer with five business functions and three maturity levels. BSIMM benchmarks observed activity prevalence across a study population. NIST SSDF specifies the regulator-facing secure-development practices (PO, PS, PW, RV). DSOMM is the pipeline-and-runtime layer specifically: how the CI/CD pipeline, the secrets-handling, the hardening defaults, and the visibility plane mature over time. Programmes that already operate SAMM or BSIMM typically run DSOMM alongside, with the same engagement record carrying scores against multiple frameworks so the audit and the leadership view share one source of truth.
Related features
Orchestrate every security engagement from start to finish
Vulnerability management software that tracks every finding
Find vulnerabilities before they ship
Test web apps behind the login
Repository connections for SAST and SCA
AI-powered reports in seconds, not days
Compliance tracking without a full GRC platform
Monitor continuously catch regressions early
Document management for every security engagement
Every action recorded across the workspace
Run OWASP DSOMM assessments as structured records
Score sub-dimensions, capture pipeline evidence, build the roadmap, and re-score on cadence. Start free.
No credit card required. Free plan available forever.