Security teams love to report vulnerability counts. "We found 4,200 vulnerabilities this quarter" sounds like rigor, but it tells you almost nothing about actual risk. A scanner tuned to be noisy will always find more issues than one tuned to be accurate, and a codebase with more dependencies will always surface more CVEs than a lean one — regardless of how exploitable any of them are. Count-based reporting rewards teams for finding problems, not fixing them.
Mean time to remediate vulnerabilities (MTTR) flips the incentive. It measures the gap between "a vulnerability is known" and "a vulnerability is closed" — the window during which an attacker can actually use it. Equifax didn't get breached in 2017 because nobody found CVE-2017-5638 in Apache Struts; a patch existed two months before attackers walked in through the still-open door. The finding wasn't the failure. The 60+ days of exposure was.
This post breaks down why time-to-fix is the metric that actually correlates with breach risk, what realistic MTTR benchmarks look like, and how to build a program around closing the window instead of counting the holes.
Why Does Vulnerability Count Fail as a Security Metric?
Vulnerability count fails because it measures detection, not exposure, and those two things move in opposite directions as a program matures. When a team adopts a new SCA or SAST tool, or expands scanning to a previously uncovered repo, the vulnerability count spikes — not because the software got worse, but because visibility improved. A team that just onboarded 50 microservices to a scanner will show a "worse" security posture on paper than a team that scans nothing at all, which is backwards.
Count also has no relationship to exploitability or exposure. A dependency-scanning report listing "312 vulnerabilities" is nearly useless without knowing how many are internet-facing, have a public exploit, or sit in code that actually executes at runtime. Google's 2023 OSS-Fuzz and dependency research repeatedly found that the majority of flagged vulnerabilities in a typical Java or Node project live in transitive dependencies that are never invoked at runtime — real attack surface, but not equal attack surface. Treating every CVE as equally urgent because it appears on the same list is how teams end up patching a low-risk dev-only dependency before a critical, internet-facing one.
Finally, count can be gamed, intentionally or not. Suppressing a scanner, narrowing its scope, or raising its confidence threshold all reduce the number reported without touching actual risk. MTTR is much harder to game: it only improves when something is genuinely fixed, deployed, and verified.
What Does Mean Time to Remediate Actually Measure?
MTTR measures the elapsed time between when a vulnerability becomes known to your organization and when the fix is deployed to production — the entire window of live exposure. That start point matters: "known" should mean the moment a scan flags it, a CVE is published against a dependency you use, or an advisory (like a GitHub Security Advisory or a vendor's PSIRT bulletin) is issued, not the moment someone gets around to triaging it. Many teams quietly understate MTTR by starting the clock at "ticket created" instead of "vulnerability disclosed," which can hide weeks of undetected exposure.
The end point matters just as much. Remediation means the patched artifact is running in production, not that a pull request was merged, not that a ticket was marked "Resolved," and not that a patch exists upstream. The 2021 Log4Shell incident (CVE-2021-44228, disclosed December 9, 2021) is the clearest case study: a fix (Log4j 2.15.0, then 2.17.1 after follow-on issues) was available within days, yet Cloudflare, Microsoft, and multiple threat intel teams reported exploitation attempts continuing for months afterward because organizations hadn't finished redeploying — proof that "patch available" and "patch applied" are not the same event, and only the second one closes the risk window.
A defensible MTTR calculation should be segmented by severity (critical/high/medium/low), because a single blended average hides the number that matters most: how fast you close critical, internet-facing vulnerabilities specifically.
How Long Does It Really Take Teams to Fix Vulnerabilities Today?
Most organizations take far longer to remediate than their own SLAs claim, with independent research consistently putting real-world averages at 60-100+ days even for high-severity findings. Edgescan's annual Vulnerability Statistics Report has repeatedly found mean time to remediate for high-risk vulnerabilities in the 60-65 day range across web application and API testing, with internal network vulnerabilities often taking longer than internet-facing ones because they're deprioritized despite similar severity. Veracode's State of Software Security research has found that roughly a quarter of high-severity flaws in code remain open a year or more after discovery, and that flaws introduced by third-party libraries take meaningfully longer to close than first-party code because of the extra dependency-update, testing, and redeploy cycle.
The gap between severity rating and actual response time is the tell. A "critical" CVE with a published SLA of 24-48 hours frequently takes 2-4 weeks in practice once you account for triage backlogs, change-management windows, and the reality that most teams patch in scheduled batches rather than on disclosure. Contrast that with organizations running continuous dependency updates (automated PRs, CI gating, canary rollouts): they routinely close critical open-source vulnerabilities same-day to same-week, because the fix is a version bump that ships through an existing pipeline rather than a manually scheduled change.
Why Do Some Vulnerabilities Take Months While Others Take Hours?
The gap comes down to three factors: how the fix is delivered, how deep the dependency sits, and whether a human has to be in the loop. A vulnerability with an automatic version-bump fix — say, a patched minor release of a well-maintained npm or PyPI package — can go from CVE publication to deployed fix in hours if a team has automated dependency updates and CI-gated deploys, because the "fix" is mechanical: bump the version, run the test suite, ship.
Compare that to a vulnerability buried three or four levels deep in a transitive dependency tree, where the immediate dependency hasn't yet released a version pinning the fixed sub-dependency. Here, remediation is blocked on someone else's release cadence, and teams are stuck choosing between an unofficial override (a package.json resolution or Maven dependency exclusion), waiting, or vendoring a patched fork — all of which add days to weeks of triage and testing before a fix ships.
The third factor is process friction: manual ticket routing, unclear ownership between security and engineering, and change-approval boards that only meet weekly. A vulnerability discovered on a Tuesday but reviewed by a change board that meets on Thursdays effectively has its clock reset to whenever that meeting happens — a purely organizational delay that has nothing to do with technical difficulty and everything to do with workflow design.
What Does a Good MTTR Benchmark Look Like?
A defensible target looks like same-day to 72 hours for critical, internet-facing vulnerabilities with a known exploit, 7-14 days for critical vulnerabilities without active exploitation, and 30 days for high-severity issues — with lower-severity findings on a 90-day cadence rather than "someday." These aren't arbitrary: they roughly track CISA's Known Exploited Vulnerabilities (KEV) Catalog guidance, which requires U.S. federal agencies to remediate KEV-listed vulnerabilities within 15 days for critical findings and 25 days for others, and they reflect the reality that the highest exploitation risk for any CVE occurs in the first 7-14 days after public disclosure, when proof-of-concept exploit code typically appears.
The benchmark that matters most, though, is trend, not absolute number. A team at 45 days average MTTR that's falling to 20 days over two quarters is in a fundamentally healthier position than a team holding steady at 15 days that hasn't moved in a year — the second team has likely optimized for the easy fixes and stalled on the structurally hard ones (deep transitive dependencies, legacy services without CI, vendor-dependent patches). Segmenting MTTR by "self-serviceable" (version bump, automated PR) versus "blocked" (waiting on vendor, requires refactor) remediation paths tends to be more actionable than a single blended number, because it tells you whether to invest in automation or in unblocking specific dependencies.
How Safeguard Helps
Safeguard is built around closing the exposure window, not just counting what's open. Instead of a static vulnerability count, Safeguard tracks time-to-remediate as a first-class metric across your entire software supply chain — source repos, build pipelines, SBOMs, and deployed artifacts — so you can see not just what's vulnerable, but how long it's been vulnerable and where the clock started.
Concretely, Safeguard helps reduce MTTR in three ways. First, it correlates vulnerability data with real reachability and exposure context (is the vulnerable function actually called, is the service internet-facing, is there a known exploit), so triage prioritizes the handful of findings that matter instead of the full list, cutting the time teams spend deciding what to fix first. Second, it automates the mechanical part of remediation — surfacing safe upgrade paths, opening pull requests for patchable dependencies, and verifying the fix through your existing CI before it's marked resolved — so version-bump fixes move from discovery to deployed in hours instead of weeks. Third, it gives security and engineering leaders a live MTTR dashboard segmented by severity, exploitability, and blocked-versus-self-serviceable status, so instead of reporting "we found 4,200 vulnerabilities," they can report "our mean time to remediate critical, exploitable vulnerabilities dropped from 34 days to 9 days this quarter" — a number that actually tells the board, the auditor, and the security team whether the risk window is shrinking.
Counting vulnerabilities tells you how hard you're looking. Measuring time to fix tells you how safe you actually are. Safeguard is built to move that second number, not just the first.