If a team stops updating dependencies, the costs do not arrive evenly. Early months feel free, the middle months add exposure and drift, and the last months bring runtime support questions and a large upgrade. This is a hypothetical timeline, not data from any company, built to show where intervention is cheapest.
How to read this
The months below are illustrative. Your pace depends on how many dependencies you have, how active they are, and how often advisories appear. The pattern is what matters: gaps compound, they do not just add.
Months 1 to 3: invisible
Builds pass. A few patch releases pass you by. The lockfile still resolves to the same versions. Nothing hurts, so nobody notices the decision has been made. Catching up now takes an afternoon.
Months 4 to 6: exposure begins
Advisories appear for packages you use, including nested ones. Some have fixed versions. Because you have not updated, each fix requires moving through several intermediate versions. Under semantic versioning, minor releases should stay backward compatible, so this stage is usually still manageable in a day or two, if you start.
Months 7 to 9: majors arrive
One or more core libraries ship a new major with breaking changes. Other libraries begin requiring it. You can still stay on the old major, but your options narrow. A security fix may appear only on the newer line. Catching up is now a project measured in days.
Months 10 to 12: support and trust
A runtime approaches a published end of life date. Python describes support lasting about five years per release, and Node.js lists end of life status for versions past support. A customer questionnaire asks how current your components are, and the honest answer takes effort to assemble. Catching up is now a sprint or more, and it competes with the roadmap.
Summary table
| Period | What accumulates | Catch-up effort |
|---|---|---|
| 1 to 3 | Patch releases missed | Hours |
| 4 to 6 | Fixable advisories | A day or two |
| 7 to 9 | Major versions, narrowing options | Days |
| 10 to 12 | Support dates, buyer questions | A sprint or more |
Where to intervene
The cheapest point is always the next one. A few practices keep you off this curve:
- Automate pull requests for outdated dependencies so updates arrive in small pieces.
- Review them weekly.
- Match your inventory to known exploited vulnerabilities monthly.
- Track runtime support dates on a calendar.
- Schedule one major upgrade per quarter, oldest first.
What if you are already at month twelve
Do not try to do everything. Take the known exploited and reachable items first, then patches and minors in batches, then majors one at a time. The recovery plan matters more than the diagnosis.
Safeguard's SBOM and dependency scanning lists direct and transitive packages with their versions, and reachability analysis shows which outdated or vulnerable ones your code actually calls. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how a fix that already exists can be applied quickly, then imagine it blocked by older versions.
Quick check
Is this timeline based on real data?
No. It is an illustration of how costs tend to compound, not a measurement. Use your own advisory and merge dates for real numbers.
What is the best single intervention?
A weekly review of automated update pull requests. It converts the curve into a flat line.
Sources
- Semantic Versioning 2.0.0
- Status of Python versions
- Node.js releases
- OWASP Top 10:2021, A06 Vulnerable and Outdated Components
Last reviewed: 19 October 2026.
