If a patched version exists and your tests pass, update. If the patch breaks something, apply a temporary mitigation and plan the larger change. If the library is abandoned, replace it. Record the decision either way, and have the right person approve any accepted risk.
The starting point from OWASP
OWASP's Vulnerable Dependency Management Cheat Sheet says a project's security posture rests partly on its third party dependencies, and recommends automated analysis of dependencies from the start of a project, because adding it late can create a large backlog. It describes cases by situation. When a patched version has been released, the ideal condition is that automated tests exist for the features using the dependency. The approach: update the version in a testing environment, run the tests, push to production if all pass, and if some fail, update the code to fit the new library and rerun.
It adds that when the vulnerable package is a transitive dependency, action is usually taken on the direct dependency, because acting on a transitive one often affects stability. It also says that accepting a risk should be decided by the chief risk officer, with a fallback to the chief information security officer, based on technical feedback from the development team.
A decision flow for a storefront team
| Situation | First move |
|---|---|
| Patched version exists, tests cover the feature | Update on staging, test, ship |
| Patched version exists, tests fail | Fix calling code, rerun, or use a temporary mitigation |
| Fix only in a breaking major version | Interim mitigation, then plan the upgrade |
| No patch, library abandoned | Replace it |
| Advisory exists, vulnerable function never called | Document the reasoning, monitor, upgrade on the next cycle |
OWASP's guidance on mitigation wrappers says to identify the reachable calls to affected functions and the conditions needed to exploit the issue, use a wrapper only when its checks block those conditions on every affected call path, and treat it as temporary while you track the real fix.
Steps
- Identify which direct dependency brings in the vulnerable one. A lockfile or a dependency inventory shows the chain.
- Check whether your code reaches the vulnerable function. See how reachability cuts the noise for why this matters.
- Pick a row from the table and write the decision, owner and date in the ticket.
- Test on staging with checkout, login and refund paths first, since they carry the most risk.
- Ship, then rescan to confirm the advisory is cleared.
- If risk is accepted, record who approved it and set a review date.
Why record the decision
A quiet accepted risk is often forgotten. A dated record with an owner makes it a managed item rather than a surprise, and it is the evidence an auditor or a customer questionnaire may later ask for.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how advisories shrink to the ones your code actually reaches.
Safeguard offers reachability analysis and SBOM and dependency scanning, and the free scan is at gold.safeguard.sh/scan.
Quick check
Should I upgrade the transitive package directly?
OWASP advises acting on the direct dependency, since changing a transitive one can destabilize the application.
Who can accept a risk instead of fixing it?
OWASP says the chief risk officer, or the chief information security officer as fallback, using the development team's technical analysis.
Sources
Last reviewed: 19 October 2026.
