When a security upgrade breaks the build, do not abandon it and do not force it through. Isolate the failure, read the release notes for breaking changes, fix the call sites or tests, and if that takes time, apply a temporary mitigation or pinned patch with a recorded expiry. Then finish the upgrade.
Step 1: Confirm the upgrade is the cause
Create a branch with only the version bump. If the build still breaks, the upgrade is the cause. If it passes, a different change interfered. Compare the lockfile diff too, since an upgrade often moves other packages with it.
Step 2: Read what changed
Open the release notes or changelog between your version and the fixed one. Look for removed functions, changed defaults, new minimum language versions and renamed options. Version numbers hint at risk but do not guarantee it, so read rather than assume.
Step 3: Check whether a smaller jump exists
Sometimes the fix was backported to your current major version. Look for a patch release on your existing line. A smaller jump breaks less.
Step 4: Fix forward in small pieces
- Update call sites for removed or renamed functions.
- Adjust tests that assert old behaviour.
- Run the full suite, not only the failing test.
- Test the paths that touch the vulnerable code first, since that is what matters.
Step 5: If it will take time, mitigate
You may need days or weeks. Pick a stopgap, and record it.
| Stopgap | When it fits | Record |
|---|---|---|
| Vendor patch or backport | Fix exists on your major version | Version and source |
| Disable the vulnerable feature | It is optional | Config change |
| Restrict access to the affected path | It is reachable from few places | Network or auth rule |
| Add input validation in front | Flaw is input driven | Test case |
| Replace the library | Abandoned or repeatedly vulnerable | Migration ticket |
Create an exception with an owner and expiry date so the stopgap does not turn permanent.
Step 6: Check reachability and exploitation
If the vulnerable function is never called and the flaw is not known to be exploited, you may have more time. If it appears in the CISA Known Exploited Vulnerabilities catalogue, the clock is short, so move straight to a mitigation while you fix forward.
Step 7: Learn from it
Add a test that covers the behaviour you depended on. Update dependencies more often so jumps are smaller. A team that updates weekly meets one small break at a time. A team that updates yearly meets all of them at once.
Try it yourself
Open the demo to see a fix proposed for a vulnerable dependency, and check what is validated before a change is offered.
Click through it at your own pace, or open it full screen.
Quick check
Can I just ignore the finding until the build is fixed?
Not without a decision. Record a mitigation or exception with an owner and expiry, so the risk is accepted knowingly.
How do I avoid big breaking jumps in future?
Update dependencies on a regular cadence, so each change is small and the release notes are short.
Safeguard's autonomous remediation with fix pull requests is off by default with every category on Manual, so you review each proposed change before it merges. Try a free scan to see the findings behind it.
Sources
Last reviewed: 19 October 2026.
