Open Source Vulnerabilities: Minding Your Blind Spots
Ten years ago, Gartner’s State of Open Source Software Report rejected the nay-sayers and said of open source that ” … if you do not think you use it, then you use it; and if you think you do use it, then you use lots more of it than you know.”
Today, the same can be said to organizations using vulnerable open source components, and the continuous growth of the open source community has finally put open source security management in the limelight.
The heightened awareness to security vulnerabilities in open source components has spurred security researchers in enterprises and in the open source community to analyze and review code with a fine-toothed comb. As a result, the number of published security vulnerabilities has hit an all-time high, met by a very high percentage of quick fixes published by the community, usually within days from the release date.
So Many Open Source Vulnerabilities, So Little Time
According to WhiteSource’s recent report about Open Source Vulnerabilities Management, which included results of a survey conducted among over 650 developers, most developers consider open source security vulnerabilities to be one of their top challenges and are putting in the resources to prove it.
Survey results showed that developers invest an average of 15 hours each month addressing open source security vulnerabilities. That time is divided between tasks like researching the vulnerability and its impact on the application’s security, as well as reporting it to other teams or managers in their organization. Surprisingly, only 3.8 of those 15 hours are spent on remediation. It appears the rest of the time is spent trying to figure out the issues and how to deal with them.
Considering the fact that the number of known open source vulnerabilities continues to grow, and there is still no standard practice for their management, it’s no wonder that development teams are often incapable of addressing all of the vulnerability alerts that they receive. In the end, they invest an outsized proportion of time sorting through alerts and attempting to determine which open source vulnerabilities they should get to first.
Is Every Vulnerability Critical?
While some headlines might make it seem like any open source vulnerability is cause for alarm, the reality is that not all vulnerabilities are critical. Determining which vulnerabilities require the most immediate attention is a challenge for development teams, especially since prioritization is another strategy with no standard best practice across the software development industry.
A new approach to assessing open source vulnerabilities should be based on their impact on a product’s security. A vulnerable functionality does not necessarily make a project vulnerable, since the proprietary code may not be making calls to it, rendering the vulnerable functionality ineffective. When WhiteSource researchers analyzed open source Java components, they found that only 30 percent of reported vulnerabilities are effective, meaning that the proprietary code is making calls to a specific vulnerable functionality within the open source component.
This discovery provides us with a new way to address open source vulnerability management. Having data that tells us which functionalities directly impact the code can enable developers to substantially lower the number of alerts that they have to deal with on a daily basis.
Removing the Blind Spots: The Tangled Web of Open Source Dependencies
A major blind spot for many development teams dealing with open source security is dependencies, which have become a widespread issue in today’s development environments because open source libraries are highly interconnected. Without an automated tracking tool, it’s nearly impossible for developers to know how many and which open source libraries they are using, due to the many direct and transitive dependencies.
This is where WhiteSource’s Effective Usage Analysis technology can step in and help automate this process. It performs trace analysis in your software, pinpointing the location where a vulnerable, effective functionality is used, and which other components are dependent on it. The results of the beta testing were published in our State of Open Source Vulnerabilities Report, and provide valuable data and insights on open source vulnerability management and prioritization.
In the beta testing, 100 percent of the projects analyzed were found to have at least one open source vulnerability, in many cases much more than one, with the average of 8.2 vulnerable libraries per project. The importance of tracking open source inventory continuously was highlighted when we discovered that 90 percent of the vulnerabilities were located in transitive dependencies.
Beyond proving how important accurate tracking of open source usage is, the necessity of assessing an open source vulnerability’s impact on a project as part of a remediation prioritization strategy also came in loud and clear when we found that 86 percent of all open source vulnerabilities alerts were found to be ineffective — meaning they had no impact on the security of the projects. In addition, 64 percent of all analyzed projects required no remediation since they only contained ineffective open source vulnerabilities, and did not require any remediation efforts.
Full Visibility Is Key to Open Source Vulnerability Management
For years we’ve been saying that the first step in open source security management is knowing what you have. With the number of known open source vulnerabilities breaking new records every year, we need to advance to the next stage with technologies that can help us to manage these alerts.
Development and security teams that don’t want to drown in the deluge of security alerts need to eliminate the blind spots that might come with open source components and gain full visibility into their software projects. This means knowing what you have in your open source components, including all of their direct and transitive dependencies, and running continuous tracking of any known open source vulnerabilities that they might contain.
Trace analysis can enable developers to navigate this maze, providing full visibility over their projects, including open source vulnerabilities, pinpointing the critical that could impact their security. These actionable insights provide developers with the information that they need to prioritize remediation in a way that both ensures that they stay ahead of security risks, and keep on schedule developing and shipping the software and services their customers depend on.
Feature image via Pixabay.