Most security teams can answer "which tools do we run?" in seconds — SAST here, SCA there, a secrets scanner bolted onto CI, maybe a container image scanner if someone got around to it. Fewer can answer "are our developers actually getting safer over time?" That gap matters more than it used to. By 2026, the median enterprise engineering org runs 8-12 discrete AppSec tools, yet breach data keeps showing the same root causes: leaked credentials, unpatched dependencies, and vulnerabilities that sat in a backlog for months after detection. Tool coverage tells you what's plugged in. It says nothing about whether findings get fixed, whether risky behavior is declining, or whether a team of 40 developers is meaningfully more secure this quarter than last.
This post is about building a developer security maturity model that measures outcomes instead of installations — one that scores remediation velocity, secrets hygiene, dependency freshness, and behavioral trendlines rather than a checklist of deployed scanners.
Why does tool coverage fail as a maturity signal?
Tool coverage fails because it measures deployment, not behavior change, and the two routinely diverge. An organization can have SAST, SCA, and secret scanning running on 100% of repositories and still ship credentials to production — because coverage answers "is the scanner watching?" not "did anyone act on what it saw?" This is the pattern behind a large share of real-world incidents: the 2023 Toyota exposed-GitHub-token incident and the 2022 Uber breach both occurred inside organizations that already had scanning infrastructure in place. The tools worked. The findings piled up in dashboards nobody triaged. A maturity model built on "tools installed" would have scored both organizations as advanced. A model built on "median time from detection to remediation" would have flagged them as high-risk long before the breach.
What does a real developer security maturity model measure?
A real model measures four things: detection coverage, remediation velocity, recurrence rate, and secure-default adoption — with the last three weighted more heavily than the first. Detection coverage (percentage of repos, pipelines, and services actively scanned) is table stakes and should sit near 100% for any team past the "getting started" stage. The signal is in what happens next: remediation velocity (median and p90 time-to-fix by severity), recurrence rate (how often the same vulnerability class reappears in new commits after a team has been trained or tooled against it), and secure-default adoption (what fraction of new services start from a hardened template versus get retrofitted later). NIST's Secure Software Development Framework (SP 800-218) and the SLSA provenance levels both implicitly encode this same shift — they grade process and evidence, not tool inventory. A team stuck fixing the same SQL injection pattern in three different services over six months is less mature than a team with fewer tools but zero recurrence.
How do you benchmark remediation behavior instead of detection alone?
You benchmark it by tracking time-to-remediate as a distribution, not an average, split by severity and by team. A single mean SLA number ("we fix criticals in 9 days") hides the tail that actually creates risk — the p90 or p95 fix time is where breaches live, because attackers don't need the median vulnerability, they need the one that sat open for 120 days because it was deprioritized behind a feature deadline. Set explicit SLA targets by severity (a common baseline: critical within 72 hours, high within 7 days, medium within 30 days) and then measure compliance against those targets monthly, per team, not just org-wide. A team that closes 95% of criticals within SLA but has a backlog of 40 unresolved highs from Q1 2025 has a maturity problem that an aggregate "vulnerabilities open" count will never surface. Segmenting by team also exposes where investment is needed — a maturity model should identify that the payments team remediates in a median of 2 days while the internal-tools team averages 45, and route enablement resources accordingly instead of applying a blanket policy.
What role do secrets and dependency hygiene play in scoring maturity?
They play an outsized role because both are leading indicators that correlate more tightly with actual breach risk than scan coverage does. Verizon's Data Breach Investigations Report has repeatedly found that credential-related exposure factors into a majority of breaches — the 2024 edition put credentials among the top initial access vectors across multiple sectors. A mature developer security program tracks secrets-related metrics specifically: number of live secrets found in git history (not just current HEAD), mean time to rotate a leaked credential after detection, and the percentage of new commits that trigger a secrets alert (a proxy for whether pre-commit hooks and developer habits are actually working, versus catching problems only after merge). Dependency hygiene follows the same logic: track the age distribution of dependencies with known CVEs, not just the count, since a 3-year-old unpatched library with a critical CVE is a fundamentally different risk than a two-week-old one still inside a normal patch cadence. A model that scores "zero secrets found in production configs this month" alongside "average dependency patch lag of 14 days" gives a far more honest maturity signal than "we scan 100% of repos."
How often should a maturity model be re-scored, and what changes the score?
It should be re-scored monthly at minimum, and continuously if your tooling supports it, because developer security maturity is a trendline, not a certification. A quarterly or annual assessment (the cadence common to compliance-driven programs like SOC 2 Type II reviews) tells you where you stood at a point in time; it doesn't tell you whether a June incident response postmortem actually changed behavior by September. What changes the score in practice: onboarding a new team without secure-default templates (drags the average down even if existing teams improved), a spike in dependency updates after a high-profile CVE disclosure (like the September 2024 XZ Utils backdoor, which triggered a wave of dependency audits industry-wide), or a shift in remediation ownership from a central security team to embedded developers (which typically raises velocity but can temporarily raise recurrence until habits form). Re-scoring monthly, segmented by team and by risk category, is what turns a maturity model from a one-time audit artifact into an operating metric that engineering leadership actually watches.
How does a maturity model stay honest instead of becoming vanity metrics?
It stays honest by anchoring every score to an outcome an attacker would care about, not an activity a team completed. "Number of PRs scanned" is an activity metric — it goes up regardless of whether anything improved. "Median days a critical vulnerability remains exploitable in a running service" is an outcome metric — it can only improve if real risk went down. The test for any maturity metric should be: can this number go up while the organization gets less secure? If detection coverage rises because a team added a fifth overlapping SCA tool without fixing more findings, that's vanity. If remediation velocity rises because a team started auto-closing tickets without verifying the fix, that's also vanity — which is why a maturity model needs a recurrence check paired with every velocity metric, confirming that closed findings stay closed in the next scan cycle rather than reappearing three sprints later.
How Safeguard Helps
Safeguard is built around the premise that supply chain security maturity is a behavioral trendline, not a tool inventory checklist. Instead of reporting "scanners deployed," Safeguard tracks the metrics this post argues actually matter: median and p90 remediation time by severity and by team, recurrence rate for previously-fixed vulnerability classes, live-secret exposure in git history versus current state, and dependency age distribution weighted by CVE severity — all updated continuously rather than at quarterly audit time.
Concretely, Safeguard gives engineering and security leaders a per-team maturity score that segments where enablement is needed instead of applying one policy org-wide, SLA compliance dashboards that surface the p90 tail hiding behind a healthy-looking average, and secrets detection that scans full commit history so a rotated-but-still-present credential doesn't silently pass as resolved. For teams working toward SOC 2, NIST SSDF, or SLSA attestation, Safeguard maps these behavioral metrics directly to the evidence auditors ask for — turning "we have tools installed" into "here is the trendline proving our developers are measurably more secure than they were last quarter."
If your current maturity reporting stops at coverage percentages, that's the gap to close first. Safeguard can show you what your remediation velocity, recurrence rate, and secrets exposure actually look like today — and track whether the investments you make next quarter move them.