Median time to fix by ecosystem: what public data says and does not

There is no single trustworthy median time to fix for every package ecosystem. Public studies measure different things: how long a library stays vulnerable, how fast a maintainer patches, or how long your dependency stays outdated. The numbers below are real but not comparable, and this note says why.

The short, plain version

If you are not an engineer: "time to fix" can mean three different clocks. One starts when a flaw is introduced. One starts when it is publicly known. One starts when a fix exists and measures how long a project waits before using it. Studies pick different clocks, so their numbers do not line up.

What did the studies find?

Clock 3: how long projects stay on a vulnerable dependency. Researchers at North Carolina State University studied npm, PyPI and Cargo packages and defined a measure of how long a package spends using an outdated and vulnerable direct dependency. They report ranges rather than medians. The middle half of packages fall between 10 and 42 days for npm, 12 and 45 days for PyPI, and 6 and 24 days for Cargo. They analyzed 163,207 packages, and could compute the vulnerable-dependency measure for 22,513 of them. Their conclusion is that most packages update relatively fast, with long tails: the worst case for one related measure was 2,653 days.

Clock 2: how fast maintainers respond after disclosure. A study of 3,362 CVEs in the Maven ecosystem found response times fell with severity: 151 days for low severity and 78 days for critical, a 48.3 percent reduction.

Clock 1: how long flaws last overall. SecurityWeek, reporting on GitHub's 2020 Octoverse security report, wrote that Ruby vulnerabilities typically took seven years to address and npm five years. The same article says vulnerabilities often went undetected for more than four years, and once identified a fix was typically released in just over four weeks. The article does not define how the durations were calculated, and the data is from 2020.

Why can't we put these in one table?

Because they disagree by design. The Maven figure counts days to patch after disclosure. The NC State figure counts time in a vulnerable state for dependency users. The GitHub figure appears to include years before anyone noticed. A project can have a four week fix and a five year lifespan at once, if the flaw sat undetected for 4 years and 11 months.

Other limits apply. The NC State authors note that their data may be incomplete, that they weighted all vulnerabilities equally regardless of severity, that they looked only at direct runtime dependencies, and that results may not generalize beyond three ecosystems. None of the three sources reports a median for npm, PyPI and Maven side by side.

What should a team do with this?

Do not benchmark yourself against a number from a different clock. Measure your own: days from public disclosure to your fix, split by severity and by whether the flaw was reachable from your code. That is the figure that predicts your exposure.

Reachability analysis changes the answer you get. If most findings are not reachable, your median time to fix reachable flaws can be short even when the raw list is long. Report both numbers.

What to do

1. Choose which clock you are measuring and write it down.
2. Record disclosure date, fix date and severity for every dependency flaw you handle.
3. Split results by reachable and not reachable.
4. Report the median and the 90th percentile, not only the average.
5. When quoting an outside number, quote the source, the clock and the year.
6. Review the figures quarterly and compare with your own earlier quarters.

Quick check

Sources

• Rahman, Paramitha, Enck, Williams: How Quickly Do Development Teams Update Their Vulnerable Dependencies? (arXiv)
• Tracing Vulnerabilities in Maven: A Study of CVE lifecycles and Dependency Networks (arXiv)
• SecurityWeek: GitHub says vulnerabilities in some ecosystems take years to fix (3 December 2020)

Last reviewed: 18 October 2026.