My project relies on a specialized component which is stuck (by its configuration) to an older version of the framework my project is using. This makes updating to the latest version of the framework impossible.
What are the best practices when dealing with this type of issue?
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
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 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.
The critical thing to sort out is the nature of your dependency. Does the older version provide one thing that your project needs or many things? Does the newer version provide one thing or many things for your project?
It's very important to look at the framework through the lens of your projects needs. This keeps you from fixing problems that you don't need to care about.
If you can identify a few needs that your project has that are creating a dependency on some version of the framework you can externalize these dependencies as library calls. Remove direct knowledge of the framework from the inner parts of your app that depends on it. Satisfy those needs through calls to adapters that hide which version or even which framework is satisfying them.
Configure those adapters at the top of your call stack. This is usually in main. Here is where you decide what will satisfy what needs.
Doing that will reduce the amount of code that has any idea which version of the framework is being used. You would be free to use multiple versions for different parts, create adapters that give you the old features with the new version, or write your own solutions that reduce your reliance on the framework.
If that sounds like a lot of work that's only because it is. Frameworks love to make you dependent on them. Keeping them at arms length so that you remain in charge takes effort.
