In our last post, Open Source Vulnerability Database, we looked at the variety of sources out there for detecting open source vulnerabilities, and the importance of tracking them all. Yet, once you detect a vulnerability within one of your components, how do you deal with it? When the inevitable happens and the time comes to tackle a vulnerability, every organization needs to have an open source vulnerability management policy in place. This will help them to quickly choose the most effective method for dealing with the issue, and get back to the business of producing great software.
I’d like to share with you our best practices regarding how to deal with vulnerable open source components. Here are our 8 steps:
#1: Awareness is the Foundation of Open Source Vulnerability Management
Tracking your open source usage is the most crucial step in knowing what open source components you’re using, since without knowing that – how can you detect vulnerable components? You could choose to track your usage manually or with automated tools, as long as you are able to track it accurately. You should be aware that one of the biggest challenges software development teams face regarding open source usage tracking are problematic coding practices, like copy and pasting. So ensuring your developers are integrating open source components in a way that allows usage visibility is critical to enable proper open source vulnerability management.
#2: So You Have a Vulnerability, but Are You Vulnerable?
You might have a vulnerable component in your software, but does that necessarily mean your software is at risk of exploitation? The simple answer is no.
For example, your organization’s system can contain the new SQL injection vulnerability, but you are not vulnerable if your software is only connected to your internal network. Understanding if you are at risk of exploitation or not is not as easy as it seems. To be 100% sure you’re not vulnerable with your current system structure, you need to fully analyze and understand the vulnerability, on top of having a complete knowledge of your entire system architecture.
Patches are our number one choice for remediation. This is because they only fix the vulnerable method in the component, without changing the rest of the component. Therefore, you’re able to fix the vulnerability with very little fuss.
But what if the patch is incompatible with your system, or is poorly developed causing software regression. Or maybe there’s no patch. In this case, what’s the next option for effective open source vulnerability management?
#4 Updating the Source File
The consensus is that the next preferable stage before updating the entire version of the component is just updating the buggy source file. This means any changes made to the component will be minimal, resulting in less chance of system instability caused by possible incompatibility between the revised component and your system. For, after all, no one wants to solve an issue just to create another one!
However, if the vulnerability affects more than just one source file, or if a new source file isn’t available, you’ll probably have to go for an option which may have a bigger knock-on effect regarding your system.
#5 Updating to a Newer Version
If applying a patch or updating a specific file aren’t available, the next option is updating the entire component to a newer version. After all, the whole point of a newer version is to address bugs and offer fixes to previous issues.
However, this solution might cause system issues, as the new component version may be incompatible with other used components. Also, the upgraded version may not be backward compatible if any issues do arise. Therefore, it may be a good idea to upgrade the version first in a sandbox, to make sure it doesn’t create any system instability.
Yet, what do you do if there is no new version available, you experience system instability or heaven forbid, the new version contains bugs of its own. In this case, your development team may need to get their hands a little dirty.
#6 Blocking Vulnerable Methods
If the above options aren’t possible, your developers can choose to integrate the vulnerable component, but rewrite its APIs, blocking the use of vulnerable methods within that component.
It is true that your developers’ code might contain vulnerabilities of its own, but proprietary vulnerabilities are always preferable to known open source vulnerabilities since open source vulnerabilities and the information how to exploit them is visible to all.
However, it’s possible that the component won’t work without its vulnerable function, causing your development team even more of a headache. So. What’s the next step in effective open source vulnerability management?
#7 Changing System Configuration
Many vulnerabilities only affect a particular system configuration, so by changing your system, you may not be at risk of a particular vulnerability.
For example, if you’re running a Linux-based or Mac OS X operating system, you might be at risk of Shellshock. So, by changing your OS to Microsoft, you no longer would have to worry about the vulnerability.
However, this is not a case of ‘out of sight, out of mind’. For it’s important to remember that the vulnerability would still exist in your old system. So if you ever did choose to revert to the old system, the vulnerability would rear its ugly head again.
But, what do you do if the vulnerability isn’t specific to a particular system configuration, or your organization is heavily tied to a particular system, e.g. your entire server stack is running on Ubuntu. Is changing your system configuration really an option?
#8 Finding an Alternative
If none of the above options are possible, the final option in your arsenal of open source vulnerability management best practices is finding an alternative.
Your developers will either have to find an alternative open source or commercial component that performs the same function. But, if no similar component is available, and the vulnerability is severe, your engineers will have to go to the trouble of writing the code themselves.
This option is really unlikely, though, since the open source community is quick to offer patches or new versions once a vulnerability is detected, especially in the case of high-severity ones.
Have No Fear. Effective Open Source Vulnerability Management is Here!
There are many ways to remediate your open source vulnerabilities. Sometimes you can take an easy route, but other times it may be more complex. But one thing is 100%, you will have to deal with that vulnerability.
To help you with this, WhiteSource has just released a new automated mitigation feature which provides our customers with recommendations (such as those listed above) on how to remediate detected vulnerabilities within their system, without having to do the legwork of searching them out themselves. For, after all, the focus of organizations likes yours is getting great products to market at ever faster speeds.
So, with this handy guide to open source vulnerability management best practices, the next time you detect an open source vulnerability, you will know exactly what steps you can take to deal with it.