Replace opinions with evidence. Check whether the vulnerable code is reachable, test the override on one service, roll out in stages, and if the risk is real but the fix is not ready, record a time-boxed exception with an owner. Both sides are protecting something, so the process should protect both.
What each side is really saying
Security: "This version has a known fix, and leaving it exposes us." Developers: "A forced version might change behavior and take down a service."
Both can be true. The override tools make the standoff worse, because they are easy to apply. npm's documentation describes overrides as a way to replace a package in the tree with another version, and Yarn's resolutions field lets you instruct the package manager to use a specific version instead of anything the resolver would normally pick. Easy to apply does not mean safe to apply.
Step 1: Narrow the question
Ask three things in order:
- Is the vulnerable package actually in the shipped artifact, or only in dev and test tooling?
- Is the vulnerable function reachable from the service's code paths?
- Is there a fixed version, and is it a patch, minor or major step?
Many disputes end at question 1 or 2. A not-reachable finding can be recorded as such, and tracked for later, without forcing a risky change.
Step 2: Test on one service
Pick the service with the best test coverage and apply the override there. Run the full test suite, plus any contract or integration tests. Record the result. A passing test run on a representative service turns "it might break" into data.
Scope the override narrowly where the tool allows. npm supports overriding a package only when it appears under a specific parent, which limits the blast radius.
Step 3: Roll out in stages
| Stage | What happens | Exit condition |
|---|---|---|
| Canary | One low risk service on the override | Tests pass, no errors for an agreed period |
| Wave | A few more services | No regressions reported |
| Full | Remaining services, or the central version list | Owners confirm |
Keep a rollback plan: the override should be a single, reviewable change that can be reverted.
Step 4: If it still cannot ship
Sometimes the fixed version is a major jump and the test suite fails. Then choose one of these, openly:
- Upgrade the direct dependency that pulls in the vulnerable version, if a newer release of it exists.
- Apply a mitigation, such as disabling the vulnerable feature, and record it.
- Accept the risk for a stated period, with a named owner, a review date and a compensating control.
None of these is a failure. An unrecorded decision is.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fix being available is shown separately from whether it is safe to apply, which is the gap this dispute lives in.
Where Safeguard fits
Safeguard's dependency scanning and reachability analysis supply the first two facts above. Autonomous remediation with fix pull requests is available and is off by default, so a team decides when proposed changes appear. Try a free scan at gold.safeguard.sh/scan.
Quick check
Should security be allowed to merge overrides directly?
Only if your policy says so, and ideally not into services it does not own. A better pattern is a pull request from security, reviewed by the service owner using CODEOWNERS.
What if tests are thin?
Say so in the record, use a smaller canary, and add a targeted test for the behavior the dependency provides before rolling out wider.
Sources
Last reviewed: 19 October 2026.
