Safeguard
Research•

Median time to fix a vulnerability by ecosystem: what data exists

No public dataset gives one clean median fix time per ecosystem. These are the figures that exist, how each was measured, and how to track your own.

Safeguard Security Team
5 min read

There is no single published median time to fix vulnerabilities across every ecosystem. The figures that exist measure different things: maintainer patch delay in Maven, dependency update lag in npm, PyPI and Cargo, and how long alerts stay open in GitHub repositories. Quote each with its definition, and compute your own median.

This note collects the numbers we could confirm from primary or academic sources on 18 October 2026, and says what each one does and does not tell you. If you want to link to one page for "how long do fixes take", link to the original papers below, not to a rounded headline.

What does the published data say?

Maven, maintainer response. An academic study of 3,362 CVEs affecting 190,945 releases across 1,470 Maven artifacts reports the average time to mitigate after public disclosure, where the patch came after the advisory: 151 days for low severity, 123 for moderate, 84 for high and 78 for critical. The authors treat it as a proxy, because CVE discovery dates are missing and maintainers may have known earlier.

npm, PyPI and Cargo, dependency lag. A separate study of 163,207 packages (117,129 npm, 42,777 PyPI, 3,301 Cargo) measures how long a package keeps using an outdated or vulnerable direct dependency. For the vulnerable case (called MTTRdep), the interquartile range is 6 to 24 days for Cargo, 10 to 42 for npm and 12 to 45 for PyPI. It could be computed for only 22,513 packages. The paper reports no per-ecosystem medians for that metric, and it says the measure is only a partial proxy for real remediation time.

GitHub, open alert age. Reporting on GitHub's 2020 Octoverse security analysis of more than 45,000 active repositories said vulnerabilities typically took about 7 years to address in Ruby and about 5 years in npm. The article does not say whether these are medians or averages, and it dates from December 2020, so treat it as history.

Why can't these numbers be compared?

Three things change between studies.

The clock starts at different moments: advisory publication, first detection in a repository, or the date a fixed version exists. The clock stops at different moments too: a patch release, an upgrade in a dependent package, or a merged pull request in an application.

The statistic differs. Means are pulled up by a long tail of abandoned packages. A median hides that tail. A 90th percentile exposes it.

The population differs. A study of widely used Maven artifacts says little about a private service with fifty direct dependencies.

What do rules of thumb say instead?

Some targets are policy, not measurement. The UK Cyber Essentials requirements (v3.3, April 2026) say updates that fix critical or high risk vulnerabilities, meaning CVSS v3 base score of 7 or above, must be applied within 14 days of release. CISA's Known Exploited Vulnerabilities catalog lists a due date per entry; on the day we checked, one entry added on 2026-09-29 was due 2026-10-13, which is also 14 days, and several added in early October were due three days after being added. These show what regulators expect. They do not describe what teams achieve.

How do you compute your own median?

Pick one clock and keep it. A common choice is "advisory published or finding first seen" to "fixed version deployed". Report the median and the 90th percentile per ecosystem and per severity, and report the count of open items older than your target. Exclude findings you have formally accepted or marked not affected, and keep a separate count of them so the exclusion is visible.

If you track reachability, split the numbers into reachable and not reachable findings. A fast median on unreachable noise is not a healthy sign.

What to do

  1. Choose a start event and an end event, and write them down.
  2. Export your findings with both dates for the last 12 months.
  3. Compute median and 90th percentile per ecosystem and severity.
  4. Compare against your own target (14 days is a common external one for severity 7 and above).
  5. Review the oldest 10 items each month and decide to fix, accept with an expiry, or mark not affected.
  6. Cite definitions whenever you quote a figure, yours or someone else's.

Quick check

Is there an official median fix time for npm?

Not in the sources we could confirm. The npm figures we found are an interquartile range of dependency lag and a 2020 news report of years, each measuring a different thing. Compute your own.

Are the Maven numbers medians?

No. The paper labels them averages, with a caveat that the exact computation is not fully specified. Use them as an order of magnitude by severity only.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.