The beliefs that justify skipping dependency updates are understandable and mostly wrong in the same way: they judge today's risk and ignore how the cost compounds. Here are six, each with the fact that corrects it. Use this as a short script when the topic comes up in planning.
Myth 1: "If it works, do not touch it"
Fact: Working code can still include a known flaw. OWASP lists using vulnerable or out of date components as a category of its own, and notes organizations are at risk if they do not fix or upgrade platforms, frameworks and dependencies in a timely way. Working and safe are different properties.
Myth 2: "Updates break things, so fewer is safer"
Fact: Fewer updates means each one is larger. Semantic versioning puts breaking changes in major releases. If you skip a year, you may take several majors in one go, which is where breakage and debugging pain concentrate. Small frequent updates fail small.
Myth 3: "Only critical severity matters"
Fact: Severity is a starting point. CISA's catalog of known exploited vulnerabilities exists because exploitation in the wild is a stronger signal than a score. A lower rated flaw that attackers are using can matter more than a higher rated one nobody has touched.
Myth 4: "We pinned our versions, so we are safe"
Fact: Pinning protects you from surprise changes, which is good, but it also freezes known flaws in place. A pinned version does not age gracefully. Pin for reproducibility and update on purpose.
Myth 5: "Our scanner would tell us"
Fact: A scanner reports known issues in components it can see. It will not tell you a library is unmaintained, nor that a runtime is close to its end of life date, unless you also track those. Python and Node.js both publish support status for each release, which you can compare against what you run.
Myth 6: "We will do a big upgrade later"
Fact: Later is more expensive. The window for known fixes stays open, the number of majors behind grows, and other libraries may now require the newer API. A scheduled routine is cheaper than a heroic project.
Quick reference
| Myth | Better framing |
|---|---|
| It works | It works, and may be exposed |
| Updates break things | Big updates break things |
| Only critical counts | Exploited and reachable count |
| Pinned is safe | Pinned is stable, not current |
| Scanner covers it | Scanner plus support dates |
| Later is fine | Later is costlier |
How to use this
Pick the myth you hear most often and answer it with the matching fact in your next planning meeting. Then propose one small change, such as a weekly update review, so the answer is concrete.
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
Is it ever right to skip an update?
Yes, for a specific reason: a breaking change you have scoped, a vendor constraint, or a short freeze. Skipping without a reason or a date is the problem.
Does updating introduce supply chain risk?
It can, since a new release might be malicious or broken. A short waiting period and review of changes reduce that risk without giving up routine updates.
Sources
- OWASP Top 10:2021, A06 Vulnerable and Outdated Components
- Semantic Versioning 2.0.0
- CISA Known Exploited Vulnerabilities Catalog
- Status of Python versions
- Node.js releases
Last reviewed: 19 October 2026.
