Vulnerability remediation is the process of identifying weaknesses and design flaws in your applications, prioritizing findings based off of the level of risk they pose, and then performing appropriate actions to resolve them. Options for vulnerability remediation include remediating (fixing) an issue, ignoring it (when it is not risky enough to merit the resources needed to fix it), or applying compensating controls to help counteract the risk posed by the vulnerability.
Vulnerability remediation options
1. 'Rip and replace' vulnerable components
In application security, the most common approach to vulnerability remediation, 'rip and replace', is exactly as it sounds: it involves fixing the problem by 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, however.
Our annual Open Source Security and Risk Analysis Report on open source in commercial applications 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. It is therefore critical that the components being used for the 'replace' step in this process also be scanned, as it is likely they too could be host to additional vulnerabilities.
The chart below is taken from Black Duck SCA's public facing Open Hub. Looking up a component in Open Hub provides information on the number and type of vulnerabilities. You can use this to determine which version you want to switch to, and decide whether to stay within a major version, or switch versions. The latter choice may provide fewer security issues, but this needs to be weighed against your risk appetite and the level of effort required to switch versions when changes to the APIs may complicate code refactoring.
At some point, continuing security issues or a declining level of support from the open source community may spur you to look for similar components. In this case, Open Hub provides a list of similar projects, as rated by the Open Hub community of over 300,000 users.
2. Patch vulnerable components
At times, a vulnerability will be isolated and require changes to only 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 vulnerability remediation a relatively simple task.
We see a 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 have to assess whether this is something for which you want to take on long-term responsibility.
3. 'Punt' vulnerability remediation approach
There are circumstances when 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 by the vulnerability may be deemed acceptable by the business. Another example could be that the vulnerability is not reachable. In many open source components, the feature set expands over the years. If the vulnerability is in functionality you aren’t using or that you can comment out, it becomes a non-issue.
Remember, absolute security doesn’t exist, and you probably don’t want to fix every vulnerability. The goal of application security is to support business goals and reduce risk to an acceptable level (residual risk is inevitable).
4. Apply compensating controls
Finally, we come to the option of applying compensating controls in order to remediate vulnerabilities in your applications. Think of these as activities we can take in lieu of replacing the vulnerable code by reducing risk to an acceptable level. Additionally, we may decide to fix the vulnerability but can’t do so for 90 days due to development schedules or the complexity of the fix. In those cases, we need to mitigate the risk posed by a vulnerability until you can fix the vulnerability.
How? 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. You may even find that the compensating controls you implement mitigate the risk to an acceptable level for your organization, and eliminate the need for actual vulnerability remediation in this case.
Finally, in many cases, understanding the artifacts generated by the exploit is a good practice regardless of how quickly you can remediate a vulnerability. Remember that these vulnerabilities have often been in the code base for years prior to public disclosure. Heartbleed, for example, was present in OpenSSL for over 2 years. Shellshock was present in Bash for 25 years! Just because a vulnerability that has been present for years was only disclosed recently, it's a mistake to believe that nobody had prior knowledge of the issue.
How we can help
Application security requires constant diligence. Integrating tools like Black Duck into a CI/CD process allows early detection of security issues in the open source you use. Hourly updates to our KnowledgeBase provide you with information on new vulnerabilities in your code – without requiring rescanning.
-This blog was reviewed by Mike McGuire.
Continue Reading
Solving telecom network security challenges with Defensics
Apr 15, 2024 / 3 min read
SANS report: Securing the shifting landscape of application development
Apr 03, 2024 / 2 min read