Most DevSecOps rollouts fail for a reason that has nothing to do with tooling: they ask engineers to absorb new work with no change to how that work is measured or rewarded. Datadog's 2026 State of DevSecOps study, built from telemetry across tens of thousands of production applications, found that 87% of organizations it analyzed have at least one known-exploited vulnerability (a CVE on CISA's KEV catalog) live in a deployed service right now, and that dependency upkeep remains the single most persistent gap teams fail to close. That is not a scanning problem — these organizations mostly already own scanners. It is an incentive problem: security work competes for the same sprint capacity as roadmap features, and roadmap features are what get a team promoted. DORA's long-running Accelerate research adds the more hopeful half of the picture: elite performers who deploy on demand, keep lead time for changes under one hour, and restore service in under an hour also carry stronger security posture, because smaller batch sizes and faster recovery shrink the window an exploit has to matter. The lesson for engineering leaders is that adoption is a management design problem before it's a technical one. This piece lays out a concrete playbook — which metrics to publish, which to avoid, and how to structure guardrails so resistant teams adopt them without a mandate memo.
Why do DevSecOps rollouts stall even with good tooling in place?
Rollouts stall because leadership introduces a new scanning gate without changing anything else about how the team is evaluated, so the gate reads as pure overhead. A team lead who is judged on sprint velocity and feature delivery has no rational reason to prioritize a security backlog that nobody above them tracks — the incentive gradient points entirely one direction. Datadog's 2026 research reinforces this by identifying CI/CD systems themselves, particularly GitHub Actions workflows, as a common and growing supply-chain attack surface: pipelines get built fast under delivery pressure and rarely get revisited once they work, because nobody's scorecard includes pipeline hygiene. The fix isn't more scanning — it's making the thing you want teams to do visible in the same forum where delivery metrics already get discussed, so it competes for attention on equal footing rather than living in a separate security dashboard nobody outside the security team opens.
Which metrics actually change engineering behavior, and which just generate noise?
Metrics change behavior when they are specific, owned, and hard to game; they generate noise when they're raw counts that punish teams for factors outside their control. Multiple 2026 industry sources — Datadog, Jit, and Cloudaware among them — converge on a similar core set: mean time to remediate (MTTR) for critical findings, remediation and retest pass rate, an exploitability ratio that blends CVSS severity with EPSS likelihood and code reachability, percentage of critical assets under active security coverage, security debt backlog age, secrets-exposure incident count, gate exception rate, and time-to-owner-assignment. Notice what's absent: total open vulnerability count. A raw count rewards teams for having small, simple services and punishes teams that own large, business-critical systems, regardless of how well either team manages risk. Backlog age and exploitability-weighted MTTR normalize for that — they measure whether a team is closing the gap on things that matter, not how big their surface area happens to be.
How do CISA KEV and EPSS make incentive metrics fairer?
CISA's Known Exploited Vulnerabilities catalog and the Exploit Prediction Scoring System (EPSS) make incentive metrics fairer because they separate "theoretically dangerous" from "actually being exploited," which is the difference between a metric engineers trust and one they route around. A CVSS score alone tells you a flaw is severe in the abstract; EPSS estimates the probability it will be exploited in the next 30 days, and KEV confirms it already has been, somewhere, against someone. If a team's scorecard treats every CVSS 9+ finding as equally urgent, engineers quickly learn that half their "critical" backlog is unreachable code or a library they don't invoke — and they lose trust in the whole system, including the parts that are genuinely urgent. Weighting the exploitability ratio by KEV membership and EPSS percentile, alongside reachability analysis of whether the vulnerable function is even called, keeps the metric honest: it flags the CVE that's live in the wild and reachable from an internet-facing endpoint far above the one that's severe on paper but dead code. That precision is what lets a scorecard drive urgency instead of fatigue.
What does a guardrail structure that resistant teams actually adopt look like?
A guardrail structure gets adopted when it enforces consistently and auditably without requiring a security engineer to personally chase down every team, because that consistency is what convinces engineers the rule isn't arbitrary or selectively applied. Policy-as-code guardrails — the kind Safeguard enforces across IDE, commit, CI, registry, admission, and runtime checkpoints — let leadership define a rule once (block any KEV-listed critical from reaching production, say) and have it apply identically whether the PR comes from a tenured staff engineer or a new hire's first commit. Two design choices matter most for adoption. First, effects should default to WARN before BLOCK during rollout, so teams see the friction coming rather than getting surprised mid-sprint. Second, every blocking guardrail needs a time-boxed exception path — an approver can grant a defined-duration exception, it logs to an audit trail, and emergency breakglass cases require two-person approval — because a gate with zero escape valve just gets disabled by the first team that hits a false positive under deadline pressure. Auditable exceptions convert "the security team blocked my launch" into "here's the documented tradeoff we accepted and when it expires."
How should engineering leaders present these metrics without triggering blame culture?
Present them at the team level, trended over time, and paired with resourcing decisions — not as a leaderboard of individual failures — because a metric introduced to assign blame gets gamed, hidden, or ignored within a quarter. The forum matters as much as the metric: a program-overview view that shows open critical findings by environment, KEV-in-production count, and rolling 30/90-day time-to-remediate trends, reviewed in the same engineering leadership sync where deployment frequency and change-failure rate already get discussed, normalizes security posture as one more delivery signal rather than a separate audit. DORA's research gives leaders a useful framing here: teams with strong delivery metrics — short lead times, low change-failure rates — already tend to have stronger security posture as a byproduct of good engineering discipline, not a separate initiative bolted on top. Framing security debt-age trends alongside deployment frequency reinforces that connection instead of setting the two in competition for the same sprint capacity. Boards and executives, meanwhile, want the single rolled-up number — KEV-in-production should be zero, backlog age should be shrinking — while team leads need the underlying detail to act on it.
How Safeguard helps
Safeguard's built-in Program Overview and Vulnerability Backlog dashboards track exactly this metric set out of the box — rolling 30/90-day time-to-remediate, aging buckets from under 7 days to over 90, KEV-in-production counts that should read zero, and exploitability-ranked findings that combine reachability with EPSS and KEV data — so leaders don't have to build a scorecard from scratch before they can start the incentive conversation. Guardrails enforce the policy side of the playbook: BLOCK, WARN, or AUTO_FIX effects at IDE, commit, CI, registry, admission, and runtime checkpoints, each producing a signed, replayable audit record, with time-boxed exceptions and two-person breakglass approval built into the exception workflow rather than bolted on afterward. Every dashboard metric also exports as an OpenTelemetry gauge or counter — safeguard.findings.open, safeguard.sbom.coverage_ratio, safeguard.griffin.autofix.prs_total — so a team's security metrics can sit in the same Grafana or Datadog board as their deployment frequency and change-failure rate, which is exactly the shared-forum framing that turns a mandate into a habit.