Measuring how fast teams remediate CVEs is straightforward in principle: record when a finding is first detected, record when the fix is merged and deployed, compute the interval. In practice, we ran into a few design choices that shaped our results significantly, and explaining them upfront saves confusion about what the numbers actually mean.
How We Defined the Dataset
We tracked remediation time across teams that had been using a scan-only workflow for at least six months before we began measurement, and a separate cohort that had adopted scan-plus-fix tooling, where a proposed code change accompanies each finding. Both cohorts were running the same underlying scanner, differing only in whether a fix proposal was attached. We excluded findings that were resolved by closing as false positive, accepted as known risk, or not applicable to their specific deployment context. Only findings where a code change was authored and merged counted toward time-to-fix.
We also separated critical and high severity CVEs from medium and low severity ones, because the behavior patterns are meaningfully different. Critical findings get prioritized and resolved faster across both cohorts. Medium and low findings are where the largest behavioral differences appear.
The Numbers
For critical and high severity findings, the scan-only cohort resolved findings in a median of 14 days from first detection. The scan-plus-fix cohort resolved the same severity tier in a median of 6 days. This is a meaningful gap but not a surprising one. High-severity findings get attention regardless of tooling. The fix proposal compresses the time the developer spends figuring out the correct change, not the time spent deciding to act.
For medium severity findings, the contrast was larger. Scan-only teams resolved medium CVEs in a median of 47 days. Scan-plus-fix teams resolved them in 12 days. Medium severity findings are where the decision to deprioritize happens most often in scan-only workflows, because a developer receiving a medium finding without a proposed fix has to decide whether to spend the research time now or park the ticket. Most ticket it, intending to return. The fix proposal changes the calculation: reviewing a proposed change is faster than authoring one, so the threshold for acting in the current sprint drops.
Low severity findings showed the largest absolute gap. Scan-only teams had a median resolution time of 73 days for low severity CVEs, with a higher closure rate via "accepted risk" rather than actual remediation. Scan-plus-fix teams resolved low findings in 18 days. The shift here is almost entirely explained by activation energy: a fix proposal attached to a low finding makes it possible to merge a one-line change in five minutes rather than deferring indefinitely.
What the Numbers Do Not Tell You
Time-to-fix is one metric. It does not capture whether the fixes introduced regressions, whether teams started gaming the metric by closing findings they would otherwise have legitimately accepted as low-risk, or whether the overall quality of the fix review process stayed constant as volume increased.
On the regression question: we did not observe an increase in security-related regressions in the scan-plus-fix cohort during the measurement period. We are careful not to state this as a general guarantee. The teams in our early-access group have strong code review practices and did not reduce review rigor for proposed fixes. Whether those results hold for teams with weaker review norms is an open question.
On the metric-gaming question: we saw no systematic shift toward marking findings as accepted risk versus actually fixing them. If anything, the scan-plus-fix cohort had a slightly lower accepted-risk rate, which is directionally consistent with the hypothesis that fix proposals reduce the cost of action enough to make fixing preferable to deferring.
Scan Frequency Matters More Than Teams Expect
Time-to-fix is only part of the exposure window. The other part is time-to-detect: how long after a vulnerability is introduced does your scanner identify it? Teams running weekly or biweekly scans incur detection lag that is invisible in time-to-fix metrics but real in the actual exposure window calculation.
In both cohorts, teams that scanned on every PR or commit had effective median exposure windows roughly 60% shorter than teams scanning weekly, even with identical time-to-fix numbers. Continuous scanning and fast fixing are complementary, not substitutes.
The Compounding Effect on High-Volume Teams
The gap between cohorts widens as finding volume increases. Small codebases with low commit frequency show a modest advantage for scan-plus-fix. Larger codebases with many active contributors show a compounding effect: the same number of analyst hours processes more findings to closure when each finding comes with a proposed resolution.
For AppSec teams managing security across many repositories with a small dedicated team, this compounding matters practically. A two-person security team responsible for twenty services cannot give deep individual attention to every medium finding across the entire codebase. Tooling that reduces the per-finding handling cost allows the same headcount to maintain a lower median time-to-fix without triaging less rigorously.
A Note on Causality
We are tracking correlation, not running a controlled experiment. Teams that adopt scan-plus-fix tools may be systematically more mature in their AppSec practices in ways that also reduce remediation time. We cannot fully rule this out from our dataset. What we can say is that the gap held across teams with varying maturity levels, and the mechanism by which fix proposals reduce resolution time, reducing the research cost per finding, is mechanistically plausible and consistent with how developers describe their own experience.
The data supports the hypothesis. Controlled A/B confirmation would require more experimental structure than an early-access deployment provides.
