If a dependency has a known vulnerability and no patched version, apply any workaround from the maintainer, restrict or isolate the affected function, test the mitigation with realistic inputs, record a time limited exception, and start planning an upgrade or replacement. Do not treat a wrapper as a permanent fix.
Where you are in the decision
The OWASP Vulnerable Dependency Management cheat sheet sorts situations into cases. The ones relevant here are when the provider says a fix will take months, and when the provider will not fix the issue at all.
| Situation | Suggested direction |
|---|---|
| Fix coming in months | Workaround now, track the upgrade |
| Provider will not fix, or does not respond | Find a better maintained component, or patch it yourself |
| Fix exists but breaks your build | Treat as a fix you cannot adopt yet, with an interim mitigation |
Step 1: Learn what the advisory says
OWASP says to identify the reachable calls to affected functions and the conditions required to exploit the flaw. Start with the advisory, the upstream issue and any fix discussion. A vulnerability category alone does not tell you which checks would prevent exploitation, so read the actual description.
Step 2: Apply a workaround and be honest about it
If the provider shares a workaround, apply it and validate it in a test environment before production. If you add your own wrapper, the source is careful here: use a wrapper provided its checks block the exploit conditions on every affected call path. Otherwise disable or isolate the affected functionality while you pursue a fix.
An allowlist on input is the example given, and OWASP labels it as illustrative and not a general defense against remote code execution. For a payments service, that caution is useful. Input filtering for one parameter does not help if the flaw is triggered through another path.
Step 3: Test the mitigation properly
Use any provider supplied exploit as a regression test. Blocking that exact payload does not prove the library is safe. OWASP says to test alternate inputs and all reachable paths, noting that small payload changes can bypass a filter. Run your existing tests to confirm the mitigation does not break stability, especially on payment flows.
Step 4: Record an exception with limits
Your scanner will keep flagging the dependency. OWASP suggests documenting in the project README that the issue is handled while waiting for a patch. If you add the dependency to an ignore list, scope the ignore to the specific advisory rather than the package, because a package can have several vulnerabilities.
Give the exception an owner and an expiry date. If a fix has not shipped by then, the decision comes back to someone who can act.
Step 5: Plan the way out
When a provider will not fix the issue or does not answer, the guidance says to start a parallel study to find a better maintained component, and, for a commercial component, to press the provider with the help of senior risk owners. If the component is open source and you can fix it, a pull request upstream protects you and others.
Add compensating controls around the edges
Reduce exposure while you wait. Limit network access from the affected service. Reduce its permissions so a compromise reaches less. Increase logging around the affected code path. These are sensible measures, but they do not remove the flaw, so label them as interim.
Who decides to accept the risk
The same OWASP guidance says the decision to accept a security issue should be taken by the chief risk officer, with the chief information security officer as fallback, informed by the development team's analysis. In a startup, that is usually the founder or head of engineering. Write the decision down.
Where Safeguard fits
Safeguard's reachability analysis helps show whether your code calls the vulnerable function, and its dependency scanning keeps the exception visible in your inventory. Autonomous remediation with fix PRs is available but off by default. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which findings drop away once reachability is applied, and which stay.
Quick check
Is an input filter a safe permanent fix?
No. OWASP calls such wrappers temporary mitigations, and says to test alternate inputs and all reachable paths.
Should I ignore the alert in my scanner?
Just for the specific advisory, and with an owner and expiry date, never for the whole package.
Sources
Last reviewed: 19 October 2026.
