AppSec Maturity Model: OWASP SAMM, BSIMM and DSOMM

Most application security programmes can list their scanners and their findings backlog, but few can say with evidence how mature the programme is, or which practice to improve next. Three public models answer that question in different ways: OWASP SAMM measures what you do against a prescriptive model, BSIMM compares what you do with what other organisations do, and the OWASP DevSecOps Maturity Model (DSOMM) goes down to pipeline activities. This application security maturity model uses the same five appsec maturity levels as other NHI Mgmt Group maturity models, Ad hoc to Optimised, scores eight dimensions of appsec programme maturity (appsec program maturity in US usage), and shows how an application security maturity assessment with SAMM, BSIMM or DSOMM fits alongside it. It is for AppSec leads, engineering managers and CISOs who need an honest baseline, a target and a roadmap. The wider programme, including testing tools and triage, sits in the Application Security Guide.

Key takeaways

Three models, three jobs: use OWASP SAMM to assess and plan, BSIMM data to compare with peers, and DSOMM to set concrete DevSecOps pipeline targets. They are complementary, not competing.
Score dimensions, not the whole programme: application security programme maturity is uneven; a strong testing score often hides weak requirements, supply chain or secrets practice.
Level 3 (Defined) is the right first target for most organisations: a published strategy, risk-tiered requirements, testing gates with agreed criteria and remediation SLAs that are met.
Coverage decides the level. DSOMM's own scale counts an activity as fully implemented only for "(almost) all applications"; a practice on two flagship products is not organisational maturity.
Maturity must show in outcomes: fewer escaped vulnerabilities, faster fixes, fewer secrets in code and fewer recurring vulnerability classes.

The five levels

Level	Name	Description
1	Ad hoc	Security depends on individual developers and occasional penetration tests before big launches. No application inventory, no security requirements, and findings are fixed when someone escalates them.
2	Developing	An AppSec owner exists, some scanning runs in CI for some repositories, and a few teams do threat modelling. Policies are drafted, coverage is patchy and metrics are counted by hand.
3	Defined	A published AppSec strategy and policy, an application inventory with risk tiers, security requirements per tier, testing gates with written acceptance criteria, remediation SLAs, and secrets kept out of code by default.
4	Managed	Practices are measured and drive decisions. Coverage is near complete for in-scope applications, findings are correlated and routed to owners automatically, pipelines and build identities are hardened, and SLA performance is reported monthly.
5	Optimised	Root cause analysis removes whole vulnerability classes through paved-road components, metrics shape the strategy, and the programme adapts quickly to new technology such as AI coding assistants and agents.

The eight dimensions

Levels 2 and 4 sit between the descriptions shown. Score each dimension separately; the roadmap below lists what moves you from one level to the next.

Dimension	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Governance, strategy and metrics	No AppSec owner or policy	Published strategy, policy with SLAs, application inventory with owners and risk tiers	Metrics set targets and investment; strategy reviewed against business change
Requirements and design	Security considered only when a tester finds something	Requirement packs per tier (for example from OWASP ASVS) and threat models for new high-risk features	Reusable secure design patterns; threat models updated automatically from architecture changes
Secure coding and developer enablement	No guidance; no training	Role-based training, secure coding standard, security champions in most teams	Paved-road libraries remove recurring flaw classes; guidance built into IDEs and AI assistants
Security testing and verification	Annual black-box pentest of a few applications	SAST, SCA and secrets scanning on all tier 1 and 2 repositories; DAST and authenticated testing before release; gate criteria written down	Tests tuned to low noise; requirement-driven abuse-case tests in CI; hybrid testing for critical releases
Software supply chain and build	Unknown dependencies; builds on developer machines	Dependency inventory and SBOMs for released software; CI-only builds; pinned third-party actions	Signed provenance verified at deployment; dependency policy enforced automatically
Secrets and pipeline identities	Credentials in code, config and CI variables	Secrets in a vault, scanning with push protection, CI tokens scoped per pipeline	Federated, short-lived credentials for pipelines and workloads; no long-lived secrets in the delivery path
Deployment and runtime	Manual deployments; no hardening baseline	Automated deployment with hardening baselines for containers and infrastructure as code	Runtime signals feed back to development; drift detected and corrected automatically
Defect and vulnerability management	Findings in reports nobody tracks	Findings deduplicated, routed to owning teams, fixed within SLA by severity	Root cause analysis per class; recurrence and escape rate trending down

OWASP SAMM, BSIMM and DSOMM compared

Aspect	OWASP SAMM v2	BSIMM	OWASP DSOMM
Type	Prescriptive model: what to do and in what order	Descriptive study: "a descriptive model that depicts real-world practices"	Activity catalogue for DevOps and CI/CD security
Structure	5 business functions, 15 practices, two streams per practice	4 domains (Governance, Intelligence, SSDL Touchpoints, Deployment), 12 practices, 128 activities in BSIMM16	Dimensions and sub-dimensions of activities, each with risk, measure, difficulty, usefulness and level
Levels	Maturity 1 to 3 per practice and stream	Activities observed or not; comparison with participants rather than a level ladder	Level 1 to Level 5, from "Basic understanding of security practices" to "Advanced deployment of security practices at scale"
Assessment	Self-assessment with the SAMM toolbox (interview questions with quality criteria) or the open-source SAMMwise tool	Data comes from assessments of participating organisations; others can map their activities to the published list	Teams mark activities and progress (Not implemented, Started, Partly implemented, Fully implemented), with evidence per activity
Best for	Planning a programme roadmap of any size	Benchmarking investment against peers in an industry	Engineering teams setting concrete pipeline targets
Licence and access	Open, CC BY-SA 4.0	Report published by the company that runs the study; assessment is a commercial service	Open source (code GPL v3)

OWASP SAMM: the Software Assurance Maturity Model

OWASP SAMM v2 describes itself as "measurable", "technology and process agnostic" and "risk-driven". Its five business functions each hold three security practices, which are the 15 areas a SAMM assessment scores:

Governance: Strategy and Metrics; Policy and Compliance; Education and Guidance.
Design: Threat Assessment; Security Requirements; Secure Architecture.
Implementation: Secure Build; Secure Deployment; Defect Management.
Verification: Architecture Assessment; Requirements-driven Testing; Security Testing.
Operations: Incident Management; Environment Management; Operational Management.

SAMM maturity levels: every practice has three levels, with more demanding objectives at each, split across two streams. In Strategy and Metrics, stream A (Create and Promote) runs from "Identify organization drivers as they relate to the organization's risk tolerance" to "Publish a unified strategy for application security" to aligning the programme with the organisation's growth; stream B (Measure and Improve) moves from defining metrics to "Set targets and KPI's for measuring the program effectiveness" to letting metrics influence strategy. OWASP is explicit that organisations do not need the highest level in every practice.

OWASP SAMM assessment: the quick start guide has six steps: Prepare, Assess, Set the Target, Define the Plan, Implement and Roll Out. OWASP says steps 1 to 4 "are planning work" that one person can often finish in one to two days; implementation runs over months. The toolbox spreadsheet holds interview questions per activity with quality criteria, and you answer "No" unless the criteria are completely met; the scorecard then calculates current maturity. Organisations can share results anonymously with the SAMM Benchmark initiative.

BSIMM: the Building Security In Maturity Model

BSIMM is a published study of real software security initiatives, now run by a commercial software security company. BSIMM16, published in January 2026, draws on 111 organisations and describes 128 activities in 12 practices across four domains. Because it is descriptive, it tells you how common an activity is among participants, not whether you need it. A formal BSIMM assessment is a commercial engagement; a free alternative is to map your own activities to the published activity list and compare with the report's observation rates. Use it to justify investment ("most peers in our sector do this"), not as a roadmap on its own.

OWASP DSOMM: the DevSecOps Maturity Model

DSOMM "shows security measures which are applied when using DevOps strategies" and how to prioritise them. Activities sit in dimensions and sub-dimensions covering areas such as build and deployment, culture and organisation, information gathering, and test and verification, and the current model data includes an Agentic AI dimension; check the live matrix because dimensions evolve. Each activity carries risk, measure, implementation difficulty (knowledge, time, resources), usefulness, a level from 1 to 5 and references to SAMM v2, ISO/IEC 27001 and OpenCRE. Its progress scale is coverage-based: "Partly implemented" means at least half of applications, "Fully implemented" means (almost) all. The project recommends tracking progress in a gitops-like flow with evidence attached to each activity, and using DSOMM together with SAMM.

How the levels relate to SAMM and DSOMM

The mapping is a loose fit for sense-checking, not an equivalence: SAMM rates each practice and stream against three maturity levels, DSOMM levels describe activity adoption, and BSIMM has no level ladder at all.

This model	OWASP SAMM (maturity reached in practices)	OWASP DSOMM (typical activity level)	Evidence that marks the level
1 Ad hoc	Level 1 not reached in most practices	Level 1 activities missing	No inventory; no owner; pentests only before launches
2 Developing	Level 1 in some practices, usually Governance and Security Testing	Level 1 started	Some CI scanning; draft policy; some threat models
3 Defined	Level 1 in all, Level 2 in many	Level 1 to 2 activities fully implemented	Strategy, tiered requirements, gate criteria, SLAs met
4 Managed	Level 2 in most, Level 3 in some	Level 3 to 4 activities	Near-complete coverage, metrics used for decisions
5 Optimised	Level 3 where risk justifies it	Level 5 activities in high-risk areas	Vulnerability classes removed by design, programme adapts quickly

Frameworks: the dimensions map to NIST SSDF (SP 800-218) practice groups PO Prepare the Organization (governance, requirements, training), PS Protect the Software (supply chain and secrets), PW Produce Well-Secured Software (design, coding, testing) and RV Respond to Vulnerabilities (defect management); to NIST CSF 2.0 PR.PS-06; to ISO/IEC 27001:2022 Annex A 8.25 to 8.31; and to CIS Controls v8.1 Control 16.

Self-assessment questions

For an appsec maturity assessment, score each dimension from 1 to 5 using evidence from tooling and tickets, not policy statements. Your overall appsec maturity level is the lowest score among the dimensions that protect your most critical applications, not the average.

Governance: can you list every production application with an owner and a risk tier today, and who signs off the AppSec policy?
Requirements and design: what share of new high-risk features last quarter had a threat model and security acceptance criteria?
Developer enablement: which recurring vulnerability class has a paved-road component that removes it, and how many teams use it?
Testing: what share of tier 1 repositories run SAST, SCA and secrets scanning on every merge, and which findings block a release?
Supply chain: could you say within a day which applications ship a newly vulnerable library version?
Secrets and pipeline identities: how many long-lived credentials do your CI/CD pipelines hold, and when were they last rotated?
Deployment: are container images and infrastructure as code checked against a hardening baseline before deployment?
Defect management: what is the median time to fix a critical finding, and how many critical findings are past SLA?

Moving up a level

From Ad hoc to Developing

Name an AppSec owner and build an application inventory with owners and risk tiers.
Run a first OWASP SAMM self-assessment to baseline the 15 practices; it takes days, not weeks.
Turn on secrets scanning with push protection and SCA on the main repositories. See the Secrets Management Guide.
Agree severity definitions and a simple remediation SLA.

From Developing to Defined

Publish an AppSec strategy and policy with SLAs, and requirement packs per risk tier. See the Secure Software Development Lifecycle (SSDLC) Guide.
Threat model new high-risk features. See the Threat Modelling Guide.
Extend scanning to all tier 1 and 2 repositories in report mode, tune it, then enforce gates on new critical findings only, with an exception process as the rollback.
Start a security champions network and role-based training. See the Secure Coding Guide.
Move CI secrets into a vault and scope pipeline tokens. See the CI/CD Pipeline Identity Security Guide.

From Defined to Managed

Correlate findings across tools and route them to owners automatically. See the Application Security Posture Management (ASPM) Guide.
Produce SBOMs and signed provenance for released software. See the Software Supply Chain Security Guide.
Replace long-lived pipeline and workload secrets with federated, short-lived credentials.
Set DSOMM level targets per team for pipeline activities and track them with evidence.
Report SLA performance, escape rate and coverage monthly, and reassess SAMM yearly.

From Managed to Optimised

Run root cause analysis on every recurring class and fund paved-road fixes.
Feed runtime findings, bug bounty reports and incidents back into requirements and tests. See the Bug Bounty and Vulnerability Disclosure Guide.
Govern AI coding assistants and agents in the pipeline as part of the programme, with their own identities and review rules.
Use BSIMM observation rates or the SAMM Benchmark to test whether investment is in line with peers.

Metrics that show maturity

Coverage: share of tier 1 and 2 applications with SAST, SCA and secrets scanning on every merge.
Time to fix: median and 90th percentile days to remediate critical and high findings, against SLA.
Escape rate: vulnerabilities found in production or by external reporters per release.
Recurrence: repeat findings of the same class in the same application within 12 months.
Secrets exposure: secrets detected in commits per month and share blocked by push protection.
Practice maturity: SAMM result per practice year on year, against the target set in the Set the Target step.

Common failure patterns

Buying maturity: adding scanners raises findings, not maturity, if nobody owns triage and fixes.
Scoring the average: an average across 15 SAMM practices can hide a practice with nothing in place, such as Secure Build, where pipeline compromises begin, as the Codecov breach showed when a leaked storage key turned a CI script into a secrets harvester.
Secrets left out of the model: testing maturity means little if a developer can still commit a working key. The xAI API key leak stayed in a public commit for two months.
Treating BSIMM as a target list: copying the most common activities ignores your own risk; use it to compare, then plan with SAMM.
Assessing once: a baseline with no reassessment and no named owner for each target practice is shelfware within a year.

Practitioner checklist

Score all eight dimensions with evidence and record the source of each score.
Run an OWASP SAMM self-assessment for the baseline and reassess yearly.
Set Level 3 as the 12-month target, with Level 4 for secrets, pipeline identities and supply chain if you ship software to customers.
Use DSOMM activity levels as engineering targets per team, with evidence attached.
Use BSIMM only as a peer comparison, never as the plan.
Baseline the six metrics now and produce them from tooling, not spreadsheets. See the Vulnerability Management Guide.

AppSec Maturity Model: SAMM, BSIMM and DSOMM