How to Handle Open-Source Library Vulnerabilities in Enterprise Deployments Without Immediate Upgrades?

Question

We are facing a challenge with managing vulnerabilities in certain open-source libraries used in our enterprise product. The current versions of these libraries have known vulnerabilities flagged by our customer’s security team, but upgrading them immediately is not feasible due to:
	1.	Breaking critical functionalities in our product during upgrades.
	2.	Dependency conflicts with other libraries/components, impacting overall stability.

To mitigate risks, we’ve implemented the following measures:
	•	Runtime security and network access restrictions.
	•	Active monitoring for potential exploit attempts.
	•	Surface area restructuring to limit exposure.

Despite these mitigations, the security team insists on immediate upgrades to the latest versions of the libraries before production deployment, which poses challenges for functionality and compatibility.

Questions:
	1.	How do enterprises typically balance such situations, especially when immediate upgrades are not feasible?
	2.	Are there best practices or alternative strategies to address these concerns while ensuring stability and security?
	3.	How can we better communicate to customers the validity of our mitigation efforts and the risks of rushing into upgrades?
	4.	Are there specific tools or approaches used by other organizations to manage such scenarios?

Any insights or examples from similar experiences would be greatly appreciated.

Mariano Rodríguez Díaz · Answer

Hi there,

I have somewhat been in your position, in reality this is something you need to solve with your customer and get some kind of exception for those vulnerabilities (supposing a big client, they have an exception process their Security Team needs to go through). It's not always easy or even feasible depending on the vulnerability and its criticality. So you need to really understand the vulnerability and have a clear explanation why even if the vulnerability does exists you're not putting them in risk due to low exploitability or something like that and explain why that's the case. It's hard to give you more details without more context.

To answer your specific questions:

1. I don't think there's an standard way on how to handle this. It's a negotiation process where you explain your reasons and they (ideally) try to work with you on a solution.
2. This will depend on a case by case basis. I'd recommend you research the vulnerability. If you go to the CVE page or even some others, you should be able to find if there's any active exploit being used in the wild and what type of access is needed for the exploit to happen.
3. Again, this is really context dependent but you need to be able to address the vulnerability or the exploitation vector through mitigations. Usually what works is saying we cannot meet the SLA due to `X` but we can commit to fixing it in `Y` time, meanwhile these `a, b, c` mitigations are in place that lower the risk of the vulnerability from `Z` to `W`. Your customer could agree or not to your explanation.
4. All this is highly dependent even in the type of vulnerability we're talking about but WAF, GuardDuty and strict monitoring to both Metrics and Logs should help you catch any exploitation attempt, the catch is that you're being reactive in this case (the explotation already happened) and it could be too late.

How to Handle Open-Source Library Vulnerabilities in Enterprise Deployments Without Immediate Upgrades?

Add your answer

Relevant content