Because of reasons like this, dependencies are not just an asset but also a kind of liability: today's rapid development is tomorrows technical debt. Depending on the risks you forsee and want to mitigate, it can make sense to use a dependency only if
- you insulate yourself from the dependency as far as possible, e.g. as described in candied_orange's answer.
- you have a plan to either migrate away from the dependency, or can ensure timely fixes to the problems you encounter.
- for proprietary dependencies you have contracts in place with clear support levels, for example that lay out how fast security issues will be fixed, and whether there will be any penalties if that support level is not met.
- for open source dependencies you are prepared to fork the code and fix the bugs yourself, or have retained a consultant who can fix these bugs for you on short notice.
- alternatively, you are prepared to shoulder remaining risk. This might be a sensible approach for well-supported problems with a sizeable community.
E.g. for most companies it does not make sense to maintain their own Linux kernel. On the other hand, that NPM package with only a few thousand downloads? Better fork it right now.
In general, it is a good idea to have your own copies of all open source dependencies that you rely on. It is also preferable to host any packages yourself. This not only gives you the ability to fix any problems, it also gives you more control over updates, and an opportunity to review and test updates.
To which degree that is sensible depends also on how the transitive dependencies are loaded. E.g. dynamically linked libraries that will be updated through your operating system (e.g. Debian) are a lot less problematic than a statically linked binary blob.
Here, your best bet is likely to fork the problematic dependency and perform the fix yourself. If source code is not available you may need to decompile or reverse engineer it. Note that this may not be legal if the dependency was provided to you under a proprietary license, so check that first.
If the dependency cannot be fixed by you, you might need to mitigate the security risk through another approach, e.g.:
- temporarily disable your service in whole or in part.
- detect and block or sanitize inputs that could trigger the security vulnerability.
Temporarily taking down your service can give you the time needed to figure out a more permanent solution, e.g. to extract the problematic dependency to a separate process or service so that it can be deployed independently of the framework.
Note that you may be required to take reasonable steps to ensure the security of the data you process if you are subject to various privacy regulations such as the GDPR. Temporarily shutting your service down until the vulnerability can be fixed may be a reasonable measure if you have no way to fix the problem immediately.