You have four options: upgrade the parent package that pulls it in, let your package manager apply an automatic fix, override the version of the transitive dependency, or document why it is not exploitable. Pick the first that works, and always rebuild, retest and regenerate the SBOM.
First, find the path
A transitive dependency is one you did not choose. Before fixing, learn which of your direct dependencies brings it in, and which version range it asks for. In npm, the explain command prints the chain. Our post why is this package in my build shows the method.
Option 1: upgrade the parent
Often the parent has already released a version that depends on the patched child. This is the cleanest fix, because you are using a combination its maintainers tested together. Check the parent's release notes for a major version change before you accept it.
Option 2: automatic fix
npm audit fix runs a full install under the hood and, according to the npm docs, updates vulnerable packages to a version without an advisory when the remediation does not require changes to dependency ranges. If a fix would need range changes, the docs say it requires the force option. That is a signal to review, since forced changes can include major version moves.
Option 3: override
npm documents overrides as a way to make specific changes to dependencies of your dependencies, for example replacing a version with a known security issue, replacing a dependency with a fork, or making sure the same version is used everywhere. An override works, but it forces a combination the parent may never have been tested with. Use it with tests, record the reason, and remove it when the parent catches up. Other ecosystems have equivalents, such as dependency management sections in Maven, but check each tool's own documentation.
Option 4: accept, with evidence
If the vulnerable code path is never called in your application, or the affected feature is disabled, you may be able to defer. Reachability analysis helps here, because it checks whether your code reaches the vulnerable function. Write down the reasoning, the owner and a review date. Do not rely on this for flaws known to be exploited.
Choosing
| Situation | Preferred option |
|---|---|
| Parent has a fixed release | Upgrade the parent |
| Fix needs no range change | Automatic fix, then test |
| Parent is stale or abandoned | Override, plus plan to replace the parent |
| Not reachable, low exposure | Accept with evidence and a review date |
Close the loop
After the change, regenerate the SBOM and confirm the vulnerable version is gone. A removed finding in a scanner is good, and a clean SBOM is better evidence because it can be stored with the release. Related reading: advisory has no patched version.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the fixed version and the upgrade path are shown together.
Safeguard offers autonomous remediation with fix pull requests, which is off by default and keeps every category on Manual until you change it. You can start with a free scan.
Quick check
Is an override safe?
It is a valid tool but it forces an untested combination. Test it and record why it exists.
When can I accept a transitive finding?
When you can show the vulnerable code is not reachable and exposure is low, with an owner and review date.
Sources
Last reviewed: 19 October 2026.
