When a vulnerable transitive dependency will not upgrade, try these in order: upgrade the parent package, force a safe version with an override, apply a patch, replace the parent, and only then accept the risk with controls and an end date. Each step is cheaper to defend than an exception.
Why it gets stuck
A transitive dependency is one you did not choose. Your direct dependency pulls it in. The fix exists upstream, but the parent pins an old range, or has not released an update, or is abandoned. Your scanner keeps flagging a flaw you cannot reach through normal upgrades.
The options, in order
| Step | What you do | Watch for |
|---|---|---|
| 1. Upgrade the parent | Move to a newer version that depends on a fixed release | Breaking changes in the parent |
| 2. Override or resolve | Use your package manager's override feature to force the fixed version | The parent may not work with it, so run the full tests |
| 3. Patch | Apply a small patch to the dependency, kept in your repository | Maintenance burden, and you own the patch |
| 4. Replace the parent | Swap it for an alternative | Migration cost |
| 5. Accept | Record an exception with controls | Needs approval, reachability evidence and an end date |
Overrides are handy, but they test the combination nobody else tests. Run integration tests, not only unit tests.
Check before you accept
Before step 5, gather two things. First, is the vulnerable function reachable from your code? A call path result might let you record a VEX not_affected instead. Second, is the component even used at runtime, or only in build or test steps? The article on dev-dependency alerts shows how that changes priority.
If you accept
Record the full chain, not just the library name: your package, the parent, the path to the vulnerable version. Add the upstream issue link, the planned check date and an owner. Re-check weekly or monthly for a parent release, since the exception should end the day an upgrade path exists. Scope it to this asset and version, as described in scoping an exception tightly.
Help upstream
Open or upvote an upstream issue, or send a pull request to the parent. A fix upstream helps everyone who hits the same wall, and gives your exception a concrete end condition.
Where Safeguard fits
Safeguard's SBOM and dependency scanning show the full dependency path for a finding, and reachability analysis helps decide whether the vulnerable code can run.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a component sits several levels below the packages you chose.
Quick check
Is a package manager override safe?
It can be, but it forces a combination the parent was not tested with. Run integration tests and keep the override documented, with a note to remove it later.
Should I accept a flaw in a dependency that is only used at build time?
Often the priority is lower, but confirm it does not ship in the artifact. Record the reasoning either way.
Last reviewed: 19 October 2026.
