Integrating Security SLAs into DORA Metrics: Balancing Speed and Safety

Integrating Security SLAs into DORA Metrics Balancing Speed and Safety
Back to blog
The DORA Framework and the Security Blind Spot
Redefining DevSecOps Metrics: SLA Tracking Without the Friction
Introducing Time-to-Remediate (TTR)
Tracking SLA Breach Rates
Delivery Lead Time vs. Security: Resolving the Conflict

1. Shift-Left Automation and Contextual Feedback
2. Risk-Based Pipeline Gating Utilizing "Fix Campaigns" to Protect Sprint Velocity What is a Fix Campaign? The Benefits of Campaigns on DORA Metrics Conclusion Sources Integrating Security SLAs into DORA Metrics: Balancing Speed and Safety In the modern software development landscape, engineering directors face a relentless challenge: pushing code faster while keeping the application secure. The widespread adoption of DevOps practices has brought developer velocity to the forefront, largely measured by the gold standard of DORA (DevOps Research and Assessment) metrics. Under pressure to ship, an unbalanced pursuit of these metrics can inadvertently compromise security, leading to a brittle and vulnerable codebase. The solution is not to slow down but to intelligently integrate security Service Level Agreements (SLAs) into DORA metrics, achieving a harmonious balance between rapid delivery and robust safety.

The stakes have only grown. Over 48,000 new CVEs were disclosed in 2025 alone — a 20% year-over-year increase, with AI-generated code partly responsible for reintroducing long-solved vulnerability classes back into modern codebases. At the same time, DORA's own 2025 research found that AI adoption is now boosting throughput, but it continues to correlate with more instability downstream — more change failures, more rework, longer cycle times to resolve issues. Speed without a corresponding investment in control systems is exposing exactly the kind of weaknesses this article is about.

This article explores the tension between delivery lead time and security, examining how tracking time-to-remediate and SLA breaches shouldn't compete with deployment frequency. We will also delve into strategic approaches like "fix campaigns" that prevent necessary security work from cannibalizing sprint velocity and burning out engineering teams — all grounded in the latest available industry benchmarking data.

The DORA Framework and the Security Blind Spot
DORA metrics have become the lingua franca for evaluating DevOps performance, historically anchored to four core measures of velocity and stability:

Deployment Frequency (DF): How often code is successfully released to production.
Lead Time for Changes (LT): The time it takes for a commit to get into production.
Change Failure Rate (CFR): The percentage of deployments causing a failure in production.
Time to Restore Service (MTTR): How quickly service recovers after failures.
These four metrics, introduced in 2013, remain the backbone of the framework even after Google Cloud's DORA team added Reliability as a fifth outcome metric in 2022 and expanded its research into software supply chain security and platform engineering in subsequent years. But the core measures are still, at heart, about throughput and operational stability — not security.

If a team deploys vulnerable code multiple times a day without causing a functional crash, their DORA metrics can look elite even as security debt quietly compounds. That gap is no longer theoretical. Veracode's 2025 State of Software Security report — drawn from more than 1.3 million applications and 126 million findings — found that 74% of organizations now carry some level of security debt, and half carry critical security debt: high-severity, highly exploitable flaws left unresolved for a year or more. The average time to fix a flaw has climbed 47% since 2020, from 171 days to 252 days. Public sector organizations fare worse still, needing an average of 315 days to close half their known vulnerabilities, with 15% of flaws in government applications persisting for more than five years.

This creates real friction for engineering directors. Implementing stringent security checks can slow down pipelines, increase Lead Time for Changes, and decrease Deployment Frequency. The core challenge is integrating DevSecOps metrics without demoralizing developers or ruining established workflows — and DORA's own data suggests the stakes go beyond productivity. GitLab's analysis of DORA's research found that organizations with low levels of security practices had 1.4 times greater odds of high team burnout than organizations with strong security practices, and identified culture — not tooling — as the strongest predictor of good security adoption. Security and delivery health are not separate problems; they move together.

Redefining DevSecOps Metrics: SLA Tracking Without the Friction
To bridge the gap between velocity and security, organizations are expanding their DORA dashboards to include specific DevSecOps metrics. The goal is to track security responsiveness with the same rigor as deployment speed.

Introducing Time-to-Remediate (TTR)
Just as Time to Restore Service (MTTR) measures recovery from operational failures, Time-to-Remediate (TTR) measures the speed of recovery from a security failure: the duration between a vulnerability being identified — via SAST, DAST, SCA, or a bug bounty program — and the moment a patch is successfully deployed to production.

Real-world benchmarks vary widely by methodology and severity band, which is exactly why an organization needs its own baseline rather than relying on a single industry number. Edgescan's 2026 Vulnerability Statistics Report put the average mean time to remediate for high- and critical-severity application and API vulnerabilities at 54.81 days across 2025, with internet-facing critical flaws fixed noticeably faster (around 35 days) than host or cloud-based ones (around 61 days). Verizon's 2026 Data Breach Investigations Report found the median time to fully resolve a vulnerability rose to 43 days in 2025, up from 32 days the year before — a trend moving in the wrong direction industry-wide. Software companies in Edgescan's dataset had the fastest MTTR of any sector at 63 days; construction lagged at 104 days, underscoring how much "normal" TTR depends on industry and infrastructure maturity.

Tracking SLA Breach Rates
Setting strict SLAs for vulnerability remediation based on severity — for example, aligned to something like CISA's Known Exploited Vulnerabilities (KEV) framework, which typically gives federal agencies about two weeks to remediate newly catalogued actively-exploited vulnerabilities — is standard practice. But merely setting SLAs is insufficient; engineering leaders must track the SLA Breach Rate, the percentage of vulnerabilities that remain unpatched past their designated deadline.

This is where most organizations are still maturing. Research from Mondoo's 2025 State of Vulnerability Remediation report found only 40% of organizations have set a formal MTTR SLA at all, and only about half of those consistently meet it. More than half of the organizations that do set an SLA target under 24 hours for critical vulnerabilities — a target the underlying remediation data suggests most are missing. A high SLA Breach Rate combined with a high Deployment Frequency is a clear signal: a team that is moving fast but prioritizing feature delivery over essential security hygiene.

Delivery Lead Time vs. Security: Resolving the Conflict
When security SLAs are first introduced alongside DORA metrics, a common objection from development teams is that security reviews and remediation work artificially inflate Lead Time for Changes. When security teams flag vulnerabilities mid-sprint, developers are forced to context-switch, disrupting flow and jeopardizing sprint commitments. This concern is well-founded: a 2025 Seemplicity remediation operations survey found that 91% of organizations experience remediation delays, and the single largest cited cause — ahead of tooling gaps or manual processes — was collaboration and communication breakdowns between security and engineering.

How can engineering directors ensure that tracking time-to-remediate doesn't artificially suppress deployment frequency?

1. Shift-Left Automation and Contextual Feedback
   The longer a vulnerability exists in the pipeline, the more expensive and disruptive it becomes to fix. Integrating automated security scanning directly into the IDE and pull request workflows ensures developers get feedback while the context is still fresh. When security checks run concurrently with unit testing, remediation becomes part of the standard commit cycle rather than a disruptive follow-up task, minimizing its impact on overall Lead Time for Changes. This matters more than ever with AI-assisted coding in the mix: a 2026 Cloud Security Alliance benchmark survey of nearly 1,000 security leaders found 45% now cite reviewing and hardening AI-generated code as a major time drain, and researchers observed specific vulnerability classes — like injection flaws — growing over 3,000% year-over-year, largely attributable to AI-generated code reintroducing old weaknesses.

2. Risk-Based Pipeline Gating
   Not all vulnerabilities are created equal, and blocking a deployment for a low-severity informational alert frustrates developers while doing little for real risk reduction. This principle isn't just theoretical anymore — it's now federal policy. In 2025, CISA retired its long-standing Binding Operational Directive 22-01 (which set largely uniform remediation windows) in favor of BOD 26-04, "Prioritizing Security Updates Based on Risk." The new directive requires agencies to set remediation deadlines based on four contextual risk factors: whether the affected system is internet-facing, whether the vulnerability is being actively exploited, whether exploitation is automatable, and how much control a successful exploit grants an attacker. That's risk-based gating at national scale, and it's a useful model for engineering teams:

Critical/High + high exploitability context: Automatically block the PR or deployment. The SLA starts immediately.
Medium/Low, or lower real-world exploitability: Allow the deployment to proceed but automatically generate a tracked ticket mapped to a specific SLA (e.g., 30–90 days). This preserves Deployment Frequency while ensuring the security debt is documented and tracked rather than silently accumulating — which, per Veracode's data, is exactly what happens to the 26%+ of debt-carrying organizations that lack this discipline.
Utilizing "Fix Campaigns" to Protect Sprint Velocity
One of the primary reasons security integration burns out teams is the unpredictable nature of vulnerability alerts. When security work is treated as constant, ad-hoc interruptions, developer velocity plummets.

To prevent security work from destroying sprint velocity, engineering leaders are adopting the concept of Security Fix Campaigns.

What is a Fix Campaign?
Instead of forcing developers to address non-critical vulnerabilities piecemeal as they're discovered, a fix campaign aggregates related security debt into a focused, time-boxed initiative. For example, if an SCA tool identifies dozens of instances of an outdated, moderately vulnerable dependency scattered across a dozen microservices, a traditional approach might generate dozens of disruptive tickets scattered across multiple sprints. This is not a minor inefficiency: over 70% of critical security debt now traces back to third-party and open-source code rather than code teams wrote themselves, according to Veracode's 2025 research, and flaws in third-party code take roughly 50% longer to fix than flaws in first-party code — precisely the kind of repetitive, cross-service problem a campaign is built to solve.

A Fix Campaign approaches this differently:

Aggregation: The security and engineering teams group the related instances into a single, cohesive initiative.
Scheduling: The campaign is scheduled as planned work for a specific sprint or a dedicated "security focus week."
Execution: Developers tackle the upgrades systematically, often using automated refactoring or fix-suggestion tools to deploy the changes en masse.
The Benefits of Campaigns on DORA Metrics
The performance gap between organizations that manage security debt this way and those that don't is stark. Veracode's data shows top-performing organizations resolve more than 9–10% of their open flaws every month and clear half of new flaws within about five weeks; lower-performing organizations resolve less than 1% monthly and take over a year to hit the same milestone. Leading organizations keep flaws present in fewer than half of their applications, while lagging organizations exceed 85%. Structured, campaign-based remediation is a major contributor to that gap:

Protects Velocity: By transforming unpredictable security interruptions into planned, estimated work, teams maintain consistent sprint velocity.
Improves Deployment Frequency: Because fixes are batched, tested, and deployed systematically, they can actually boost deployment frequency during the campaign period.
Reduces Cognitive Load: Context-switching is the enemy of productivity. Letting developers focus solely on one class of security upgrades reduces burnout and improves remediation quality — directly addressing the burnout-security link identified in DORA's own research.
Conclusion
Engineering directors do not need to choose between moving fast and staying secure. By integrating DevSecOps metrics like Time-to-Remediate and SLA Breach Rates alongside traditional DORA metrics, organizations can gain a holistic view of their software delivery health — one that reflects reality rather than a partial, security-blind snapshot. DORA's 2025 research now goes further than the original four metrics, using a diagnostic framework of seven team archetypes to capture how performance, stability, and well-being interact; the best-performing group in that model, "Harmonious High-Achievers," pairs steady throughput with low burnout through tight feedback loops and shared ownership — the same qualities that make risk-based gating and fix campaigns effective.

The key to preventing burnout lies in how these metrics are managed. By implementing risk-based pipeline gating — now validated at federal scale through CISA's BOD 26-04 — and utilizing structured Fix Campaigns, security work stops being a chaotic interruption and becomes a predictable, manageable part of the software development lifecycle. Balancing delivery lead time with security is not about slowing down; it's about engineering a system where safety is an intrinsic byproduct of speed.

Sources
Google Cloud / DORA — 2025 DORA Report announcement
Veracode — 2025 State of Software Security report and Public Sector Snapshot
Edgescan — 2026 Vulnerability Statistics Report coverage
Verizon — 2026 Data Breach Investigations Report (via BestDefense analysis)
Mondoo — 2025 State of Vulnerability Remediation
Seemplicity — 2025 Remediation Operations Report
CISA — BOD 26-04, Prioritizing Security Updates Based on Risk
GitLab — DORA security practices and burnout findings
Security Magazine / Cloud Security Alliance — 2025/2026 Security Benchmark Report coverage