Mean time to remediate (MTTR) is the number most security programs use to track CVE response performance. It has one significant problem: the mean hides the distribution. A team that remediates ten critical CVEs within 24 hours and lets one sit for 180 days looks identical on MTTR to a team that takes 32 days for each of eleven CVEs. The first team has one serious process failure. The second team has a systemic workflow problem. The aggregated MTTR cannot tell the difference.
If your security reporting runs on MTTR alone, you're tracking a number that smooths out the failures you most need to surface.
Decompose the remediation timeline into stages
CVE remediation for a dependency vulnerability involves at least four distinct stages, each of which can be the bottleneck. Tracking MTTR without understanding which stage accounts for the delay is roughly as useful as tracking total cycle time for software releases without knowing whether the delay is in development, QA, or deployment approval.
The four stages:
Detection lag. Time from CVE publication (NVD/OSV/GitHub Advisory) to the first time your team is aware the vulnerability applies to your codebase. For teams running scheduled weekly scans, this is up to seven days by design. For teams running continuous scanning triggered by advisory publication, this is typically under an hour.
Triage lag. Time from detection to a decision on priority and ownership. This is where most teams lose the most time without realizing it. A raw CVE alert arrives. Someone has to determine if the affected package is actually reachable in production, which team owns the repo, and whether a fix version exists. In the absence of tooling, this is a human research task that takes hours to days per CVE. With EPSS probability scores, reachability analysis, and automated PR generation, it can take minutes.
Fix-available lag. Time from triage completion to the existence of a fix (a PR is open, a patch version exists, an alternative package is identified). This is the stage most teams have the least control over: sometimes the upstream package maintainer hasn't released a patched version yet. However, teams often inflate this lag by not generating the fix PR immediately after triage, leaving the CVE in an acknowledged-but-unactioned state.
Review and merge lag. Time from fix available to fix merged and deployed. This is where the human bottleneck is clearest. A PR sitting in the review queue for two weeks is not a security team problem. It's a development team prioritization problem that security reporting should make visible.
What the breakdown reveals that MTTR obscures
When you measure these four stages separately, you can identify where your specific process breaks down rather than assuming the problem is uniform across the pipeline.
A team with a 30-day MTTR might have a 1-day detection lag, a 2-day triage lag, a 1-day fix-available lag, and a 26-day review-and-merge lag. The bottleneck is clearly in the PR review queue. The solution is not better detection tooling. It's changing how dependency PRs are prioritized in the development workflow, potentially adding auto-merge for low-risk patch bumps, or establishing an SLA that keeps high-severity PRs out of the general review queue.
A different team with the same 30-day MTTR might have a 14-day detection lag (scanning only runs monthly), a 1-day triage lag, a 2-day fix-available lag, and a 13-day review lag. Two different problems. Two different interventions. The aggregated MTTR cannot distinguish them.
SLA design: severity-stratified is the only reasonable approach
Most CVE SLA frameworks set a target by CVSS severity: critical CVEs remediated within X days, high within Y days, medium within Z days. The CVSS threshold is a reasonable starting point but introduces its own distortions.
CVSS base scores don't account for exploitability in the wild or reachability in your specific codebase. A CVSS 9.5 with an EPSS probability of 0.003 (very unlikely to be exploited in the next 30 days) is practically lower urgency than a CVSS 7.0 with an EPSS probability of 0.4 and a known exploit in active use. A strict CVSS-based SLA will drive your team to remediate the theoretical 9.5 before the actively exploited 7.0.
A more defensible SLA design layers CVSS with EPSS: anything CVSS 9.0+ regardless of EPSS gets the fastest SLA. Anything EPSS 0.1+ (10% probability of active exploitation in 30 days) regardless of CVSS gets the next tier. Everything else gets a standard timeline. This is closer to how well-run security programs actually triage, but most teams haven't formalized it because their tooling doesn't surface EPSS scores alongside CVE findings.
Tracking exceptions and SLA breaches is the real measurement
A MTTR target is meaningless without tracking the breach rate. If your SLA says critical CVEs must be remediated within 7 days and you're hitting that target 70% of the time, the 30% breach rate is your actual performance indicator, not the 7-day target itself.
Repohelm's reporting surfaces open findings against their policy-defined SLA, broken out by stage. The view that's most useful in practice is not "what's our average MTTR" but "what CVEs have been in the triage-lag stage for more than 48 hours" and "what PRs have been in the review-and-merge stage for more than 14 days." Those two views surface the specific actionable items rather than an aggregate number that requires interpretation.
The measurement anti-pattern to avoid
Closing CVE findings without fixing the underlying vulnerability to improve MTTR is a pattern that appears in programs under pressure to hit targets. The most common form is marking a CVE as "accepted risk" or "wontfix" without documented rationale. This removes the finding from the MTTR calculation without changing the actual security posture.
We're not saying accepted risk is illegitimate. Sometimes a CVE is in a dev-only dependency that will never reach production, and accepting the risk with documentation is the correct call. But if the acceptance rate for a severity tier is suspiciously high, that's usually a signal that the team is optimizing the metric rather than the underlying security work. The right response is to audit the accepted-risk decisions on a quarterly basis and validate that they reflect genuine risk judgments, not queue management.
A measurement model you trust requires that the inputs are clean. Garbage-in on the triage decisions produces a MTTR number that looks healthy and reveals nothing about your actual exposure window.