Because the gap is only half the cost. While you wait, the people who understood the dependency move on, other code starts relying on its quirks, and the team loses the habit of upgrading. When an urgent advisory finally forces the work, you pay for the version gap and for rebuilding knowledge from scratch.
A story from a large engineering organisation
Google's chapter on dependency management gives a cautionary example. An engineer adds an open source package to a shared third-party directory to finish a demo before a vacation, and a teammate agrees to help maintain it. Later, other teams quietly depend on it, some of them inside critical infrastructure. Nobody notices the growth, because transitive use is easy to miss.
Then comes the day an upgrade becomes critical, for instance after a security vulnerability is disclosed. One of the two original owners has moved into management. The other has changed teams and not touched the package since. The ownership file was never updated. Thousands of projects depend on the package indirectly, and nobody has experience with its internals.
The chapter's point is that the longer a package stays stable and unchanged, the more code comes to rely on the particulars of that exact version, which makes the eventual upgrade harder.
What decays while you wait
- Ownership. People change teams. The name on the manifest or owners file is wrong.
- Context. Why was this pinned? What did we work around? The answers leave with the person.
- Reliance on quirks. More code depends on undocumented behaviour of the old version.
- Tooling. Build scripts and CI images drift, and the upgrade path itself rots.
- Habit. Teams that upgrade often have a routine. Teams that do not treat each upgrade as an unfamiliar project.
Signs your team is in this loop
| Sign | What it suggests |
|---|---|
| Nobody can say who owns a pinned package | Ownership has lapsed |
| A comment says "do not upgrade" with no reason | Context has been lost |
| Upgrade tickets keep getting pushed a quarter | Habit is gone |
| The first upgrade attempt takes a week of discovery | Knowledge has decayed |
How to break the loop
- Assign owners, by team. Review the list each quarter and update it when people move. See who owns dependency upgrades.
- Write the reason down. Every pin needs a comment and a link to the ticket that explains it.
- Upgrade in small, regular steps. Small steps keep the skill alive and the diffs readable. Our note on patch debt covers the cost side.
- Do one planned upgrade per quarter even if nothing is urgent. Treat it like a fire drill.
- Record what you learned. Short runbooks, kept current, preserve context for the next person.
It is not an argument to chase the newest release
Upgrading regularly does not mean adopting every release on day one. A cooldown rule can keep you away from brand-new versions while still moving steadily. See release cooldown policies.
What to tell leadership
Explain that deferring is not free and not neutral. Each skipped quarter compounds. A predictable, modest upgrade habit is the cheaper path, and it protects the team from the day an upgrade stops being optional.
Where Safeguard fits
Safeguard's asset discovery and SBOM scanning help keep an accurate inventory of what you run and where, which is the first thing that decays when ownership lapses. A free scan is at gold.safeguard.sh/scan.
Quick check
Is it fine to freeze a dependency that works?
For a time, yes, if the choice is deliberate, owned and dated. The risk is drifting into a freeze nobody remembers choosing.
How often should owners be reviewed?
Once a quarter, and whenever someone changes teams or leaves.
Sources
Last reviewed: 19 October 2026.
