Most security teams can't answer a simple question: what stage is our AppSec program actually at? OWASP tried to standardize the answer with SAMM v2, which scores organizations across 15 security practices — three per business function (Governance, Design, Implementation, Verification, Operations) — on a 0–3 maturity scale, deliberately agnostic to whether you ship waterfall, agile, or DevOps. Black Duck's BSIMM15 report, published in January 2025, took the empirical route instead: it measured 121 real organizations across eight verticals — down from 130 in BSIMM14 — spanning roughly 11,100 security professionals and 96,000 applications, and catalogued 128 observed activities across four domains (Governance, Intelligence, SSDL Touchpoints, Deployment). It found organizations conducting adversarial abuse-case tests more than doubling year over year, organizations employing research groups to develop new attack methods up nearly 30%, SBOM generation for deployed software up 22%, and software composition analysis (SCA) adoption on repositories up 67%. Both models are rigorous, but neither hands a team a quick, five-minute gut check. This post distills a five-stage maturity model — Ad Hoc, Reactive, Managed, Proactive, Optimizing — with concrete self-assessment criteria at each stage, mapped back to what SAMM and BSIMM actually measure.
What does Stage 1 (Ad Hoc) actually look like?
Stage 1 is the default state for any organization that hasn't deliberately invested in AppSec: security work happens only when a customer contract, an auditor, or a breach forces it. There's no dedicated security engineering headcount, no static analysis or SCA running in CI, and vulnerability remediation has no SLA — fixes happen whenever an engineer has spare time. In SAMM v2 terms, this maps to a 0 across nearly every one of the 15 practices, including the Threat Assessment and Security Testing practices under Design and Verification. Self-assessment check: if you cannot name who owns your last three security findings, or if "security review" means an engineer reads the diff before merging, you're at Stage 1. This is also where most startups sit through their first one or two years, and it isn't necessarily wrong for that stage of company — the risk is staying here past the point where your attack surface (public APIs, customer data, third-party dependencies) has outgrown ad hoc handling.
What separates Stage 2 (Reactive) from Stage 1?
Stage 2 organizations have tooling but not process — they run a scanner, but the scanner's output doesn't reliably become a fixed vulnerability. A typical Stage 2 shop has SAST or dependency scanning wired into CI (often just to satisfy a SOC 2 or customer questionnaire requirement) but no triage workflow, so findings pile up in a dashboard nobody reads. BSIMM15's own data illustrates the gap between adoption and maturity: the 67% jump in organizations running SCA on repositories reflects tool rollout, not necessarily fix throughput — a separate, much smaller number of firms in the same dataset have mature remediation SLAs. Self-assessment check: do you know your median time-to-remediate for a critical finding? If the honest answer is "we don't track that" or "it's over 90 days," you're Reactive. The distinguishing move from Stage 1 is that tools exist; the move to Stage 3 requires that findings actually get closed.
What does Stage 3 (Managed) require operationally?
Stage 3 is where security gates become enforced rather than advisory, and where a named team — even if it's one person — owns policy across the SDLC. This corresponds to SAMM scores of 2 across most Verification and Implementation practices: security requirements are defined before design starts, secure build practices (dependency pinning, signed artifacts) are standard, and a defined SLA exists per severity (commonly 15 days for critical, 30 for high). Under BSIMM's SSDL Touchpoints domain, Managed-stage organizations typically have code review with security rules embedded (not just style linting) and a security architecture review gate before major releases. Self-assessment check: can a pull request that introduces a critical CVE actually get blocked by policy, automatically, without a human remembering to check? If yes, and if that policy has an owner and an exception-approval process, you're Managed. Most mid-size SaaS companies with a compliance requirement (SOC 2 Type II, ISO 27001) land here — the audit forces the SLA and the gate to exist on paper and in practice.
What distinguishes Stage 4 (Proactive) programs?
Proactive organizations move security left of the gate entirely: threat modeling happens during design, not after a pen test finds the same issue in production. This maps to SAMM's Threat Assessment practice reaching level 2–3, where structured threat modeling is applied to new architecture before code is written, and to BSIMM's finding of adversarial abuse-case testing more than doubling year over year — Proactive shops are the ones driving that number, running red-team-style abuse cases against their own features pre-release rather than waiting for a third-party pentest. Reachability-aware triage is also a Stage 4 marker: rather than treating every SCA hit as equally urgent, teams here filter for whether vulnerable code paths are actually invoked at runtime, which is the difference cited across multiple 2023–2024 vendor studies between hundreds of open CVE tickets and the handful that are truly exploitable. Self-assessment check: does a new feature get a threat model before its first PR, and does your team distinguish reachable from unreachable dependency CVEs when prioritizing? If both are yes, you're Proactive.
What does Stage 5 (Optimizing) look like, and does anyone actually get there?
Optimizing organizations treat AppSec metrics as a continuously tuned feedback loop: remediation SLAs, false-positive rates, and mean-time-to-detect are tracked over time and used to retune tooling and training, not just reported upward. This is SAMM's level 3 across most practices — security is baked into org-wide KPIs, and Verification practices include ongoing purple-teaming rather than point-in-time assessments. BSIMM15's 121-organization sample skews toward larger, more mature firms by design (it's an opt-in benchmark of established security programs), and even within that sample, activities like continuous, metrics-driven improvement of the SSDL are among the least commonly observed of the 128 catalogued activities — meaning even security-mature companies rarely reach full Stage 5 across every practice simultaneously. Self-assessment check: do you retire or retune a security control based on measured false-positive rate rather than gut feel? Honest answer for most organizations, even good ones, is no — which is the point of a five-stage model: most programs should aim for a defensible Stage 3 or 4, not chase a Stage 5 that even BSIMM's benchmark population rarely achieves uniformly.
How Safeguard fits into this model
This maturity model is about program-level process, not a specific product — but one narrow piece of it maps directly onto something Safeguard already does in the software supply-chain slice of AppSec. Safeguard's Risk Score weights component risk across five factors — Attestation (SCAL) at 30%, Provenance at 25%, Package Health at 20%, Behavioral analysis at 15%, and Historical issues at 10% — with SCAL itself running a 0–5 tiered scale from Fully Attested down to Unknown Component. That's a real example of a tiered, weighted scoring construct operating inside a single practice (dependency trust), not a substitute for the org-wide self-assessment above. If your team is Stage 2 or 3 and dependency provenance is your biggest blind spot, a tiered attestation score like SCAL is a concrete way to move that one practice forward, even before the rest of your program catches up.