When engineers say they cannot update dependencies yet, the cause is usually one of six: weak test coverage, a breaking change they have not scoped, no time in the plan, fear of a past failure, an unmaintained library, or unclear ownership. Ask which one it is. Each has a different fix, and most are management problems, not technical ones.
Why this answer is rarely laziness
Teams that skip updates are mostly responding to incentives. Features are visible and upgrades are not. A failed upgrade is remembered for months, while a skipped one costs nothing visible until later. OWASP names the pattern directly: patching treated as a periodic task under change control leaves organizations exposed to fixed vulnerabilities for days or months. So start from curiosity, not blame.
The six reasons and what to do
| What you hear | What it usually means | A useful response |
|---|---|---|
| "We do not trust our tests" | Coverage is thin around the affected code | Fund tests for the riskiest paths first |
| "It is a major version" | Breaking changes are unscoped | Ask for a one day spike to list them |
| "No capacity" | Updates are not planned work | Reserve a fixed slice of each sprint |
| "Last time it broke prod" | Past incident, no safe rollout | Add staged rollout and a rollback step |
| "The library is abandoned" | No upgrade path exists | Plan a replacement or a fork decision |
| "Not my service" | Nobody owns it | Name an owner in writing |
Ask better questions
Replace "why is this not done" with questions that surface the blocker:
- What would make this update safe to merge on a Tuesday?
- What is the smallest step we can take this sprint?
- Which dependencies here have known vulnerabilities, and which are only old?
- If a critical advisory landed tomorrow, how long would the fix take today?
The last question is the most useful. The answer is a number of days, and it is usually longer than anyone expected, because the real work is not the patch but the upgrades that must come first.
Semver helps you scope the conversation
Semantic versioning says patch releases hold backward compatible bug fixes, minor releases add backward compatible functionality, and major releases contain incompatible changes. That gives leaders a simple way to sort the backlog. Patches and minors are usually cheap and should flow on a routine. Majors need a plan. Treating them as one pile makes everything look scary.
What leaders can actually change
- Time. A standing share of capacity beats heroic upgrade weeks.
- Safety. Staged rollouts and fast rollback reduce fear.
- Ownership. Every repository has a named owner for dependencies.
- Tooling. Automated pull requests make the small updates arrive in small pieces.
- Visibility. Report lag and open fixable advisories each month.
When "we cannot update" is correct
Sometimes it is true. A library may be unmaintained, a platform may pin you to an old version, or a vendor may not certify a newer release. In those cases ask for compensating controls and a dated exit plan, rather than an open ended wait.
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.
Quick check
Should leaders just mandate updates?
A mandate without time, tests and rollback tends to produce rushed merges. Pair any rule with the capacity and safety nets that make it achievable.
How do I know a reason is real?
Ask for specifics: which test, which breaking change, which service. A real blocker can be named in one sentence.
Sources
Last reviewed: 19 October 2026.
