✓ Human-authored analysis; AI used for formatting and proofreading.
Delivery teams have DORA. Four metrics — deployment frequency, lead time for changes, mean time to restore, change failure rate that predict whether a team is shipping well. Thoughtworks recently added a fifth: rework rate, measuring how much of the pipeline is consumed by fixing work previously considered complete.
These metrics changed how delivery organizations operate. Because they're leading indicators. They tell you the trajectory before the outcome arrives. A team with increasing lead times is heading for trouble. A team with rising rework rate is accumulating debt. You see it in the metrics before you see it in the incidents.
Security teams have no equivalent.
Finding counts. "We found 247 misconfigurations this quarter." More scanning produces more findings. A team that scans more frequently or adds a new tool sees the number go up which looks worse even if posture is improving. Finding counts measure scanning effort, not security health.
Compliance percentages. "We're 94% compliant with CIS Benchmarks." This measures the last audit, not the current trajectory. A team at 94% today might be at 87% next week if three Terraform changes introduced misconfigurations. The percentage is a snapshot, not a trend. It rewards breadth of coverage over depth. 94% across 200 checks sounds better than 100% across 50 checks, even if the 50 are the ones that matter.
Incident counts. "We had two security incidents this quarter." This is a trailing indicator. It measures failures that already happened. A team with zero incidents might have excellent posture or might have excellent luck. You can't tell. By the time the count goes up, the damage is done.
None of these answer the question delivery teams answer with DORA: are we getting better, and how fast?
The five DORA metrics adapt directly to security posture. The definitions are concrete and measurable from evaluation data that already exists.
Evaluation frequency (maps to deployment frequency): how often do you verify your posture? A team that evaluates weekly has a 7-day window where misconfigurations can accumulate undetected. A team that evaluates on every commit has minutes. The metric isn't "how often do you scan". It's how often you produce a timestamped, deterministic evaluation result that you can compare to the previous one. Frequency determines your maximum detection latency.
Time to remediate (maps to lead time for changes): the duration from when a finding first appears to when it disappears from the evaluation results. A finding that appears on Monday and disappears by Wednesday has a 2-day remediation time. A finding that appears in January and is still present in June has a 5-month remediation time. The metric tells you how long risk persists after detection. Unlike finding counts, it penalizes findings that sit unresolved rather than rewarding findings that get detected.
Mean time to remediate (maps to MTTR): the average remediation time across all findings in a period. This is the posture equivalent of "how fast do we recover?" A team with a 3-day MTTR closes findings before they compound. A team with a 90-day MTTR is accumulating open findings faster than it resolves them. The trend matters more than the absolute number — MTTR going up means the team is falling behind.
New findings per evaluation (maps to change failure rate): of all the changes that happened between evaluations, how many introduced new security findings? If every Terraform apply produces three new findings, the development process is introducing risk at a steady rate. If the number is trending down, the team's practices — code review, pre-deployment checks, policy-as-code are catching problems earlier. This is the metric that connects delivery practices to security outcomes.
Recurrence rate (maps to rework rate): findings that were remediated and then reappeared. A public bucket gets fixed. A later change re-exposes it. The finding returns. That's security rework — unplanned effort to re-fix a problem previously considered complete.
This is the most important of the five. Thoughtworks added rework rate to DORA specifically because it catches the "considered complete but wasn't" pattern. In delivery, that's a feature that ships, breaks, and needs patching. In security, it's a finding that's remediated, silently reintroduced, and caught only when the next evaluation runs or worse, when an attacker finds it first.
A rising recurrence rate is the early warning signal that remediation isn't sticking. Either the fixes are superficial (the bucket was made private but the Terraform code still declares it public, so the next apply reverts it), or the process has no feedback loop (the developer who introduced the finding wasn't told about it, so they repeat the pattern).
The data is already in the evaluation results. Every finding has a first-seen timestamp and a last-seen timestamp. Every evaluation run has a capture time. Two consecutive evaluation results contain everything needed:
import "github.com/sufield/stave/pkg/stave"
previous := stave.LoadResult("findings-2026-05-28.json")
current := stave.LoadResult("findings-2026-06-01.json")
diff := stave.Diff(previous, current)
// The five metrics, computed from the diff:
// 1. Evaluation frequency
daysBetween := current.Run.CapturedAt.Sub(previous.Run.CapturedAt).Hours() / 24
// 2-3. Remediation time (per finding and mean)
for _, f := range diff.Removed {
remediationTime := f.LastSeen.Sub(f.FirstUnsafe)
// accumulate for mean
}
// 4. New findings per evaluation (change failure rate)
newFindings := len(diff.Added)
totalAssets := current.Summary.TotalAssets
changeFailureRate := float64(newFindings) / float64(totalAssets)
// 5. Recurrence rate
recurrenceRate := float64(len(diff.Recurred)) / float64(len(current.Findings))
No dashboard or CLI command. A Go program the customer writes, runs at whatever frequency they choose, and sends wherever they want — Slack, a retrospective, a CI gate, a spreadsheet, or nowhere at all.
The library exposes the data: LoadResult
, Diff
, typed structs with timestamps. The customer decides what the numbers mean. A recurrence rate of 5% might be acceptable for one team and alarming for another. That's their judgment, not the tool's.
Thoughtworks' guidance on DORA metrics: "We recommend using these metrics for team reflection and learning rather than just building complex dashboards. Simple mechanisms, such as check-ins during retrospectives, are often more effective than overly detailed tracking tools."
A CLI command with flags and formatters is a dashboard in disguise. It embeds opinions about what to show, how to format it, and what thresholds matter. The customer gets options but not ownership.
A library function that returns typed data has no opinion. The customer writes a 20-line program that computes the metric they care about, at the frequency they choose, with the thresholds they set. If they want a Slack message when recurrence rate exceeds 10%, they write that. If they want a weekly email with remediation time trends, they write that. If they want a CI gate that fails the build when new findings exceed zero, they write that.
The library provides facts. The customer provides interpretation. Same architecture as the evaluator itself and for the same reason: the tool that embeds its own interpretation is the tool the customer outgrows first.
Used together, the five metrics tell a story that no individual metric captures:
"We're scanning more but not remediating faster." Evaluation frequency is up, remediation time is flat or rising. The team is detecting more but closing at the same rate. The bottleneck is downstream of detection.
"Remediation isn't sticking." Recurrence rate is rising. Findings get fixed and come back. The fixes are superficial, or the development process reintroduces the same patterns.
"New risk is outpacing remediation." New findings per evaluation exceeds remediated findings per evaluation. The backlog is growing. The team is falling behind.
"We're getting faster at fixing but slower at preventing." MTTR is improving, but change failure rate is rising. The team is getting better at response and worse at prevention. The investment should shift from faster remediation to fewer introductions.
"Posture is improving." All five trending in the right direction — evaluating more frequently, remediating faster, introducing fewer new findings, and seeing fewer recurrences. This is the signal that practices are working, not just tools.
No single metric tells the story. A team with zero new findings but a 30% recurrence rate is on a treadmill. A team with high new findings but a 2-day MTTR and zero recurrences is catching and fixing fast. The five together are the leading indicator of posture health. The thing security teams have been missing.
Thoughtworks flags rework rate specifically in the context of AI-assisted development: "If lead times don't decrease and deployment frequency doesn't increase, faster code generation doesn't translate into better outcomes. Conversely, degradation in stability metrics particularly rework rate provides an early warning sign of blind spots, technical debt and the risks of unchecked AI-assisted development."
The same logic applies to AI-generated infrastructure. A Terraform module generated by an AI agent ships faster. If it introduces a security finding that gets remediated and then reappears when the module is reused elsewhere, that's AI-assisted security rework. The rework rate catches it. The finding count doesn't. It just goes up by one each time.
Measuring generated infrastructure with posture DORA metrics answers the question that finding counts can't: is the AI making our cloud safer, or is it making our cloud bigger and equally vulnerable?
1. Produce two evaluation results. Run your security evaluation tool today and again in a week. Save both outputs as JSON. You now have the raw data for all five metrics.
2. Diff them. Count: how many findings are new (added), how many were remediated (removed), how many came back (recurred), how many persisted (unchanged). Four numbers. That's the posture health summary for the week.
3. Compute one metric. Pick the one that matters most to your team right now. If you're drowning in findings, compute MTTR. It tells you whether you're closing faster or slower. If you recently adopted AI-assisted infrastructure, compute recurrence rate. It tells you whether fixes are sticking. If you're trying to justify investment in prevention, compute change failure rate. It tells you how many changes introduce new risk.
4. Bring it to a retrospective. One number. One trend. "Our remediation time went from 12 days to 8 days this month" is a more useful conversation starter than "we have 247 findings." The number becomes a tool for reflection, not a dashboard to stare at.
The delivery side of the industry figured this out years ago. The security side is still counting findings and calling it measurement. The same five metrics work. The data already exists. The question is whether you compute it.
The library API for results and computing diffs is in Stave at pkg/stave/. Tutorial 12 in the stave-guide covers building custom metrics programs.