Five beliefs cause most bad upgrades: a green build means safe, patch bumps cannot break things, staging proves production, a canary needs no preparation, and every vulnerable package needs the same testing. Each is partly true and dangerous when taken as a rule. Here is what is documented and what to do instead.
Myth 1: A green build means the upgrade is safe
Fact: A green build means the tests you wrote passed. If tests use a double of an external service, they pass even if the real service changed. Martin Fowler raises exactly this: testing against a double leaves open whether the double still represents the real service, which is why contract tests exist. Tests also cannot cover inputs you did not think of.
Do instead: Keep tests, add contract checks for external services, add a short smoke test, and stage the rollout. See what a smoke test should check.
Myth 2: A patch bump cannot break anything
Fact: Semantic Versioning says a patch increments for backward compatible bug fixes, and defines a bug fix as an internal change that fixes incorrect behavior. That is an intention. Fixing incorrect behavior can break someone who relied on it, versions can be mislabeled, and in major version zero the specification says anything may change at any time.
Do instead: Scale test depth by where the package sits, not by the number. See do you need the full suite for a patch bump.
Myth 3: If it passes in staging it will work in production
Fact: Staging differs in data, traffic, scale and configuration, so it is a filter, not proof. Google's SRE guidance on canarying stresses that an evaluation must be representative in size and duration, and a staging run is usually a small sample.
Do instead: Close cheap gaps in versions and configuration, then use a staged production rollout. See why staging passes and production breaks.
Myth 4: A canary protects you automatically
Fact: A canary only helps if you compare the right things. A small canary population is diluted inside overall traffic, so a global error rate can look fine while the new version is failing. The SRE material shows the problem becomes plain when you break metrics down by version. A canary also needs enough duration to see slow failures and scheduled jobs.
Do instead: Define metrics, a per-version comparison and stop rules before you start. See how long a canary should bake.
Myth 5: Every vulnerable dependency needs the same urgent testing
Fact: Exposure differs. A package that is present but whose vulnerable function your code never calls is a different case from one on an internet-facing path. Treating all findings alike either burns the team out or hides the ones that matter.
Do instead: Use reachability and exposure to sort the work, and give the exposed, exploited ones the fast lane with a minimum test set. See the minimum testing for an emergency patch.
Summary table
| Belief | What is true | Better habit |
|---|---|---|
| Green means safe | Green means tests passed | Add contract checks and a smoke test |
| Patch cannot break | Patch intends compatibility | Test by risk, not version |
| Staging proves production | Staging is a sample | Stage the production rollout |
| Canary is automatic | Needs metrics and time | Per-version comparison |
| All findings equal | Exposure differs | Prioritize by reachability |
Safeguard's reachability analysis marks whether a vulnerable function is called by your code, which helps with Myth 5, and its gates and policies keep the checks in Myths 1 to 4 consistent on every pull request. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop out of the urgent list once reachability is applied.
Quick check
What is the quickest improvement for a team with weak upgrade testing?
Write a short smoke test, build from the lockfile, and add a staged rollout with a rehearsed rollback. Those three prevent most outages.
Do these myths apply to automated updates?
Yes. A bot changes who opens the pull request, not what the change does in production.
Sources
Last reviewed: 19 October 2026.
