Ask five security leaders to define "AppSec maturity" and you'll get five different answers — one talks about tool coverage, another about mean time to remediate, a third about whether developers even know who to call when a scanner fires. That inconsistency is exactly the problem maturity models were built to solve. Frameworks like OWASP SAMM, BSIMM, and NIST's Secure Software Development Framework (SP 800-218) replace gut feel with a scored, repeatable assessment of specific practices — from threat modeling to dependency management to incident response. They matter now more than ever: after Executive Order 14028 (May 12, 2021) and the OMB's September 2022 memo M-22-18, any company selling software to the U.S. federal government must self-attest to NIST SSDF conformance. This post breaks down what these models actually measure, which one fits your organization, and where teams consistently get the rollout wrong.
What Is an Application Security Maturity Model?
An application security maturity model is a structured framework that scores an organization's security practices against defined capability levels, rather than just counting tools or scan results. Instead of asking "do we have a SAST scanner," it asks "is threat modeling performed consistently, by whom, at what stage of the SDLC, and is the output acted on." The three dominant frameworks each take a different measurement approach. OWASP SAMM v2 (published 2020) organizes 15 security practices under five business functions — Governance, Design, Implementation, Verification, and Operations — and scores each practice from 0 to 3. BSIMM (Building Security In Maturity Model), now on version 13, is descriptive rather than prescriptive: it's built from real observed data across 130+ participating firms and catalogs 121+ activities across 12 practices in four domains. NIST SP 800-218 (SSDF) takes a compliance-oriented approach, defining 42 tasks across four groups — Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV).
Which Model Should You Actually Use — SAMM, BSIMM, or SSDF?
The right model depends on whether you need to benchmark, comply, or both — most mature programs end up mapping more than one. Choose OWASP SAMM if you're starting from scratch and want a free, self-assessable roadmap with clear 0-3 scoring; it's the most common starting point for mid-market SaaS companies because the toolkit and spreadsheet are public and take a few days to run internally. Choose BSIMM if you want to benchmark against peers using real industry data rather than an idealized target state — it's licensed through Synopsys/Black Duck and is popular with large financial services and healthcare firms that need defensible "we're in line with the industry" language for boards and auditors. Choose NIST SSDF if you sell to the U.S. federal government or to prime contractors, because since 2023 federal agencies have required a signed CISA self-attestation form confirming SSDF conformance before they can use your software. Many enterprise vendors now run SAMM internally for maturity tracking and map their evidence to SSDF tasks for the attestation paperwork — the frameworks aren't mutually exclusive.
How Many Maturity Levels Are There, and What Do They Actually Mean?
Most models use a 3- or 4-point scale, and the jump between levels is about consistency and evidence, not tooling. In OWASP SAMM, level 0 means the practice isn't performed at all; level 1 means it happens ad hoc, usually driven by one motivated engineer; level 2 means it's formalized with a defined process and some measurement; level 3 means it's optimized, with metrics feeding continuous improvement and the practice surviving staff turnover. A team that runs Semgrep in CI but has no one triaging the findings is level 1, not level 2 — the tool exists, but there's no defined process or accountable owner. BSIMM uses a similar three-tier structure per activity (levels 1-3) but reports it as observed frequency across participating firms, so "level 2" in BSIMM means roughly a third of assessed firms perform that specific activity, not that your organization hit an abstract quality bar. This distinction matters when you're reporting maturity scores to a board: SAMM level 3 is a target state, BSIMM level 3 is a population percentile.
What Does a Maturity Score Actually Measure — Process or Outcomes?
A maturity score measures whether a security process exists, is followed, and produces evidence — not whether your application is actually more secure. This is the most common criticism of these frameworks, and it's fair. A company can score SAMM level 2 on Vulnerability Management by documenting an SLA of "critical vulns patched in 15 days" while still carrying a six-month-old Log4Shell-class finding in a rarely-scanned internal service, because the process existed on paper for the services that were assessed. Maturity models are lagging, structural indicators — closer to ISO 9001 for security than to a penetration test. That's why frameworks like PCI DSS 4.0 (effective March 2024 for most new requirements) increasingly pair maturity-style process requirements with outcome-based controls like automated dependency scanning and targeted risk analyses, rather than relying on process attestation alone. Treat a maturity score as a map of where controls should exist, then verify with actual exploitability and reachability data whether those controls are catching anything real.
How Long Does It Take to Move Up a Maturity Level?
Moving one full maturity level typically takes 12 to 24 months for a mid-sized engineering organization, because the bottleneck is usually process and headcount, not tooling. BSIMM's longitudinal data shows the average participating firm's software security group has existed for roughly 4 years by the time it reaches a stable, repeatable program — going from "no SSG" to a functioning one with defined activities is itself a multi-year effort for most firms outside the initial cohort of large tech and financial companies. The realistic timeline breaks down roughly as: 1-3 months to run the initial SAMM or BSIMM assessment and get executive buy-in on a target state; 3-6 months to stand up the missing tooling (SAST, SCA, SBOM generation, secrets scanning) and assign explicit process owners; 6-18 months to get the process followed consistently enough, and with enough evidence, to pass a re-assessment at the next level. Organizations that try to compress this into a single quarter almost always end up with theater — a policy document with no enforcement — rather than an actual level increase.
What Are the Most Common Mistakes Teams Make When Adopting a Maturity Model?
The most common mistake is treating the assessment as the deliverable instead of the improvement plan, and it happens in a majority of first-time rollouts. Teams spend six weeks running a thorough OWASP SAMM assessment, produce a 40-page scorecard, present it once to leadership, and then never revisit it — the document becomes shelf-ware because no one assigned owners or deadlines to the gaps it identified. A second common failure is scoring every application in the portfolio identically, when a maturity model is meant to be applied per business unit or per software type; a legacy internal tool and a customer-facing payments API shouldn't share a target maturity level, but many programs assess them together and end up with a meaningless organization-wide average. A third mistake is ignoring evidence requirements — SAMM and SSDF both expect artifacts (tickets, SLA dashboards, signed-off threat models), not verbal confirmation that "we do that," and assessors who accept the latter produce scores that collapse the first time an auditor asks to see the artifact. Finally, teams frequently pick the highest-effort framework (BSIMM) before they have a functioning security team to generate the activity data it requires, when starting with SAMM's lighter self-assessment would have surfaced the same gaps in a fraction of the time.
How Safeguard Helps
Maturity models tell you a process should exist; Safeguard gives you the evidence and automation to actually run it. Safeguard generates and ingests SBOMs automatically across your build pipeline, which directly satisfies the artifact requirements in SSDF's PS.3 and SAMM's Verification practices without a manual inventory exercise. Our reachability analysis distinguishes vulnerable dependencies that are actually invoked in your code paths from ones that sit dormant, so your Vulnerability Management program can move past the process-existed-on-paper problem and prioritize by real exploitability. Griffin AI, our agentic remediation engine, triages new findings against that reachability context and opens auto-fix pull requests for the ones that matter, cutting the mean-time-to-remediate metric that most maturity frameworks explicitly score. That combination — verifiable artifacts, reachability-based prioritization, and automated fixes — is what turns a maturity assessment from a static scorecard into a program that actually climbs levels year over year.