BlackDuck
By Mike McGuire, Senior Software Solutions Manager
Vulnerability remediation is the process of identifying weaknesses and flaws in your applications, prioritizing findings based on the level of risk they pose, and then performing appropriate actions to resolve them.
Below are four approaches to remediation that you can take to minimize risk to your applications.
‘Rip and replace’ vulnerable components
The most common approach is 'rip and replace'. It involves removing (ripping) the vulnerable component and replacing it with a component that resolves the vulnerability (either directly or by using a different open source project). Care should be taken to ensure you are replacing the component with a secure version.
Black Duck’s annual Open Source Security and Risk Analysis Report finds that the average vulnerability in open source components used in commercial applications is almost always several years old. This means that organizations are often failing to remediate vulnerabilities in their applications that have been publicly disclosed for years.
Patch vulnerable components
At times, a vulnerability will be isolated and only requires changes to a few lines of code. In those cases, the open source community may issue a patch to remediate the issue. When available, this option makes remediation a relatively simple task. We see formal patches issued most often in Linux distributions.
While applying a patch or rewriting the code yourself can be less disruptive in the short term, you also need to consider maintainability of the component. Rewriting the code essentially results in you branching the project, and you must assess whether this is something for which you want to take on long-term responsibility.
'Punt' vulnerability remediation approach
Sometimes doing nothing is the right decision when it comes to remediating vulnerabilities. This is typically the case when the vulnerability has a low CVSS score and a non-public facing interface. In those cases, the risk posed may be deemed acceptable by the business.
Another example is when a vulnerability is unreachable. In many open source components, the feature set expands over time. If a vulnerability is in functionality you aren’t using or that you can comment out, it becomes a non-issue.
Apply compensating controls
Compensating controls are activities that reduce risk to an acceptable level in lieu of replacing the vulnerable code. To apply them, you need information about the vulnerability and likely attack vectors.
For example, there may be rules for your IDS or IPS that can alert you, or WAF rules that can block the attack. If you execute the exploit in a test environment, you can generate data on what to look for in your SIEM.
Understanding the artifacts generated by the exploit is a good practice regardless of how quickly you can remediate a vulnerability. Vulnerabilities may have been in the code base for years prior to public disclosure. Just because a vulnerability that has been present for years was only recently disclosed, it's a mistake to believe that nobody had prior knowledge of it.