Maturity Models: DSOMM, SAMM & BSIMM

Every DevSecOps program eventually runs into a question no scanner can answer: how mature are we, actually? Two earlier pages in this course already touched pieces of the answer — the secure SDLC introduced SAMM and BSIMM at a conceptual level, and Secure SDLC Gates & the DevSecOps Maturity Model went deep on DSOMM's per-activity scoring mechanics — but neither one put all three side by side and asked the question a real team actually faces: given a real program, a real budget, and a real audience to convince, which of these do you run, and does picking one rule out the other two? This page is that full three-way comparison, plus the case against skipping all three and drafting your own scorecard in a spreadsheet on a Friday afternoon.

Three models, three different questions

☺ Like you're 10: DSOMM asks "how good is this one specific skill," one skill at a time. SAMM asks "how good is the whole program" and tells you what to study next. BSIMM doesn't grade you against a rulebook at all — it tells you exactly how you compare to everyone else who took the same test.

The three acronyms get used almost interchangeably in casual conversation, which is exactly backwards — they were built to answer three different questions, at three different altitudes, and none of them is trying to replace the other two. Getting the questions straight first is what makes the rest of this page make sense:

• OWASP DSOMM (DevSecOps Maturity Model) asks: how mature is this one specific, concrete pipeline activity, independent of every other one? Self-assessed, pipeline-technical, free, scored per-activity on a four-level scale.
• OWASP SAMM (Software Assurance Maturity Model) asks: how mature is our whole software-assurance program, from governance through operations? Self-assessed, whole-lifecycle, free, scored on a 0-to-3 scale and built to produce a multi-year roadmap.
• BSIMM (Building Security In Maturity Model) asks: what do real security programs at real firms actually do, and how do we compare? Externally observed, whole-program, typically a paid facilitated engagement, and the only one of the three that's descriptive rather than prescriptive.

Notice the pattern: DSOMM and SAMM both tell you what "good" should look like and let you grade yourself against it. BSIMM refuses to say what "good" should look like at all — it only reports what's actually observed in the wild, and leaves the judgment of whether that's good enough to you. That single design choice is the thread the rest of this page keeps pulling on.

OWASP DSOMM — one pipeline activity at a time

☺ Like you're 10: Instead of one grade for "security," DSOMM gives you a separate grade for SAST, a separate grade for secrets detection, a separate grade for container scanning — so you can be brilliant at one and still learning at another, honestly, instead of hiding behind one blended number.

OWASP's DevSecOps Maturity Model organizes technical pipeline activity into five dimensions — Build and Deployment, Culture and Organization, Implementation, Information Gathering, and Test and Verification — and inside each dimension, individual activities like "SAST," "secrets detection," "container base image scanning," or "dependency scanning" are scored independently, each on its own four-level scale, with every level defined by a specific, checkable criterion rather than a vague adjective. A team is never simply "mature" or "immature" under this model; it has a profile, and two teams that both claim "we do SAST" can sit at wildly different levels once you ask which specific criteria they actually satisfy.

# Simplified illustration of one activity's scoring inside a DSOMM self-assessment.
# The project's exact current activity list and level wording live at the OWASP
# DSOMM site and have been revised across releases — treat this as illustrative,
# and check the live version before citing exact wording anywhere it matters.

dimension: Implementation
activity: Static Application Security Testing (SAST)
level_achieved: 2
levels:
  1: "SAST runs somewhere in the pipeline; results are visible but not enforced"
  2: "SAST runs on every commit; high-severity findings block the merge"
  3: "Findings are triaged against an SLA; the false-positive rate is tracked"
  4: "Ruleset is tuned per-repository; new rules are piloted before enforcement"

The assessment itself is self-service: a team (usually the platform or DevSecOps engineering group, not a separate assessor) works through the activity list, honestly picks the highest level it can defend with evidence, and the tool renders the result as a radar or spider chart — one spoke per dimension, showing at a glance where the profile is deep and where it's shallow. There's no gatekeeper, no fee, and no waiting for an external report; you can re-run it the same afternoon you close a gap. That immediacy is also its limit: DSOMM only ever measures the pipeline's technical mechanics. It has essentially nothing to say about whether Design ran a threat model, whether Operations has an incident runbook, or whether the organization has a security budget at all — those live one altitude up, in SAMM. For the fully worked, gate-by-gate walkthrough of DSOMM applied to a real pipeline, see Secure SDLC Gates & the DevSecOps Maturity Model.

OWASP SAMM — the whole software-assurance lifecycle, prescriptively

☺ Like you're 10: SAMM doesn't just grade the pipeline — it grades whether anyone threat-modeled the design, wrote security requirements, and has a plan for when something breaks in production. Five report-card subjects, not one.

Where DSOMM stays inside the pipeline, OWASP SAMM (Software Assurance Maturity Model) grades the entire software-assurance lifecycle. Its current structure organizes practice into five business functions — Governance, Design, Implementation, Verification, and Operations — each broken into three practices, for fifteen practices total, and each practice further split into two streams (labeled A and B) that each get scored independently on a 0-to-3 maturity scale. A "3" in a stream means the practice is not just present but measured, optimized, and continuously improved; a "0" means it hasn't started.

SAMM's own toolbox — a free, OWASP-published spreadsheet — walks an assessor (usually a security lead or an architect, working with practice owners across the org) through scoring each stream against its documented criteria, then plots current maturity against a target maturity the team sets deliberately, function by function. The gap between the two is the roadmap: "we're a 1 in Threat Assessment; getting to a 2 next year requires X." That's SAMM's real deliverable — not a single number, but a two-to-three-year plan with named next steps per practice, loosely aligned with the software-assurance process areas in ISO/IEC 27034. Notice that Secure Build and Secure Deployment, under Implementation, are exactly the territory DSOMM covers in much finer technical detail — a program often uses DSOMM's granular per-activity evidence to justify the stream score it records in SAMM's Implementation function, rather than treating the two as competing rulers for the same ground.

Notice too that Design and Operations — threat assessment, security architecture, incident management, environment hardening — are functions DSOMM never touches at all, because they live upstream and downstream of the pipeline DSOMM was built to measure. That's the real division of labor between the two models: DSOMM is a magnifying glass over one function's worth of ground; SAMM is the map of the whole territory, at lower resolution. See threat modeling for the Design-function activity SAMM scores and DSOMM doesn't, and security culture & champions for how SAMM's Education & Guidance practice usually gets staffed in practice.

BSIMM — not what should happen, what does

☺ Like you're 10: BSIMM doesn't tell you what a good security program should look like. It watches a hundred-plus real ones, writes down exactly what they actually do, and then tells you how close you are to that — which is a very different, and much harder to argue with, kind of report card.

BSIMM (Building Security In Maturity Model) is the odd one out among the three, and deliberately so. Where DSOMM and SAMM are both prescriptive — they define what a mature activity should look like and let you self-grade against that definition — BSIMM is explicitly descriptive. It was built, and is still updated annually, by observing real software security initiatives across a large cohort of participating organizations (the exact count moves with every release, but it's been well over a hundred firms for years) and recording which specific activities each program actually performs. It makes no claim about what a program should do; it only reports what real programs do do, and lets the comparison speak for itself.

Structurally, BSIMM groups 12 practices into 4 domains:

Within each practice, dozens of specific activities are each nominally leveled 1 through 3 by how commonly they're observed across the corpus — a Level 1 activity is close to a baseline most participating firms already do, a Level 3 activity is rare and sophisticated. Your own program's score for a practice is simply which of those activities you can show you actually perform, and that count gets set against the aggregate corpus, and often against a narrower vertical cohort (financial services, healthcare, independent software vendors, and so on), so you learn not just "are we doing well" but "are we doing well for a bank" or "for a SaaS vendor." That last comparison — apples to apples, against firms with a similar risk profile and regulatory load — is the thing neither DSOMM nor SAMM can give you, because both of them compare you only to their own idealized rulebook, never to another real organization.

Side by side

☺ Like you're 10: Same three report cards, now on one page — so you can actually see what makes each one different at a glance instead of holding it all in your head.

Laid out against the same set of questions, the differences stop being abstract:

Picking one — or running more than one

☺ Like you're 10: You don't have to choose just one report card. A lot of teams run the fast one every week, the medium one once a year, and the expensive outside one every couple of years — same way you'd get a checkup, a yearly physical, and an occasional second opinion.

The honest decision framework starts with the question you're actually trying to answer, not with the model's reputation:

• "Are we investing enough in this specific pipeline capability?" — that's a DSOMM question. Run it yourselves, quarterly or after any major pipeline change, and treat the radar chart as an engineering backlog, not a report to leadership.
• "Do we have an org-wide plan, and is it improving year over year?" — that's a SAMM question. Run it annually with security leadership and practice owners across Governance, Design, Implementation, Verification, and Operations, and use the target-vs-actual gap as next year's roadmap.
• "How do we actually compare to other real companies, and can we prove that credibly to a board, an auditor, or an acquirer?" — that's a BSIMM question. Budget for it every one to two years, not continuously, because its value is in the external, hard-to-fake comparison, not in fast iteration.

Mature programs rarely pick exactly one and stop. The common pattern layers all three at different cadences and different owners, with evidence flowing upward: DSOMM's continuous, engineering-owned scores become the hard evidence behind SAMM's Implementation-function ratings, and SAMM's overall self-assessment gets periodically sanity-checked against BSIMM's external, benchmarked view — so leadership isn't relying purely on the organization's own grading of itself when it matters most.

The anti-pattern: don't invent your own scorecard

☺ Like you're 10: Writing your own report card and grading yourself with it means you already know you're going to pass. That's not a report card — that's a mirror that only ever nods back at you.

Faced with three named models, project size, and unfamiliar terminology, the tempting shortcut is a homegrown scorecard: a spreadsheet with rows like "SAST: yes/no," "threat modeling: yes/no," maybe a 1-to-5 column someone made up on the spot. Resist it. A scorecard you write yourself fails in ways that are easy to predict and hard to notice from the inside:

• You grade your own homework, leniently, without knowing it. The person filling in the column also wrote the definition of what counts as a "yes" — there's no independent criterion to check the score against, so scores drift upward over time even as nothing underneath actually improves.
• It has zero external credibility. An auditor, a customer's security questionnaire, or a board member has no way to interpret "we're a 4 out of 5" on a scale nobody outside your building has ever seen. A named, published model at least has a public definition they can go read themselves.
• It doesn't survive staff turnover. The one person who remembers exactly what "Level 3" was supposed to mean leaves, and the next reviewer either guesses or quietly redefines it — so the trend line across years is comparing different rulers without anyone noticing.
• It's a solved problem you're re-solving badly. DSOMM, SAMM, and BSIMM collectively represent years of iteration by practitioners who ran into exactly this problem before you did. A spreadsheet built in an afternoon starts from zero against models that started from thousands of real assessments.

None of this means a published model has to be used exactly as-is with no judgment. Adjusting SAMM's target maturity per function to your actual risk profile, or deciding your team only needs DSOMM's Build and Deployment and Implementation dimensions this year, is legitimate customization of a validated skeleton — a different thing entirely from inventing the skeleton itself. See DevSecOps anti-patterns & pitfalls for this failure mode alongside its siblings, and the broader case for choosing an established framework over an improvised one.

Making the score stick

☺ Like you're 10: A radar chart that only ever gets shown once, in one slide, then forgotten, didn't measure anything — it decorated a meeting. The score only means something once someone re-runs it and checks whether the shape actually changed.

A maturity score that gets generated once, screenshotted into a slide deck, and never revisited is indistinguishable from not having run the assessment at all — worse, actually, since it creates the appearance of measurement without the substance. A few operational habits are what separate a model that actually drives change from one that decorates a quarterly business review:

• Match the cadence to the model. DSOMM is cheap enough to re-run every sprint or after any meaningful pipeline change; SAMM's roadmap review fits a yearly planning cycle; BSIMM's cost and setup effort make it a one-to-two-year cadence, not an annual one.
• Turn every gap into a tracked backlog item, not a chart annotation. "SAST is at Level 2, target Level 3" is only useful if it becomes a ticket with an owner and a due date — otherwise the same gap reappears, unaddressed, at the next assessment.
• Watch for Goodhart's law. Once a specific score becomes the target teams are measured against, there's pressure to satisfy the letter of a criterion without the substance behind it — merge-blocking SAST with every rule set to warn-only so the pipeline technically "runs SAST" is the DSOMM version of this; treat a suspiciously fast jump in score as a prompt to re-verify, not celebrate.
• Reuse the evidence you're already collecting. Much of what a DSOMM or SAMM assessment needs — scan logs, gate configuration, policy documents — overlaps heavily with what compliance & governance already gathers for audits, and with the automated evidence pipeline in Compliance as Code at Scale. Don't run two separate evidence-collection efforts for what's functionally the same underlying question.

The operating rhythm this all fits into — who owns which recurring review, and how a security program actually runs week to week rather than just what it measures — is the subject of Best Practices & the Operating Model. And if you're studying toward a credential rather than just running a program, these three models show up by name often enough in scenario questions that they're worth knowing cold — see CDE — Certified DevSecOps Expert.

Three models, three questions, and no requirement to pick a permanent favorite: run DSOMM where you need fast, granular, engineering-owned feedback; run SAMM where you need an org-wide roadmap with teeth; and budget for BSIMM where you need a comparison nobody can accuse you of having graded yourself. For the pipeline-level mechanics DSOMM measures in detail, see Secure SDLC Gates & the DevSecOps Maturity Model; for the evidence trail that feeds all three, see compliance & governance; and for the people side that no maturity score captures on its own, see security culture & champions.