Visibility is the key to prioritizing open source vulnerability remediations

Modern software is compiled more than it is composed, built on top of open source components to develop faster and more efficiently.

No longer a secret weapon for developers seeking to meet their tight deadlines, open source usage has come into the mainstream with the most prominent enterprises in the world, including Microsoft and Google, touting that they are users of and contributors to open source projects.  

According to industry estimates, open source components comprise 60-80% of the code base in modern applications. A recent open source vulnerability management survey of 650 developers found that 97% of respondents use open source, with 87.4% stating that they use it regularly. This means that if your team is developing software, then they are more than likely consistently using open source components for many of the core features of their products.

Open source vulnerabilities are on the rise

While organizations enjoy the powerful features that open source components provide to help  fuel their software production, they need to use them responsibly, dealing with security vulnerabilities in the components that can put their products at risk.

As the community of open source security researchers has increased their efforts to uncover new vulnerabilities in a wide range of open source software projects, the number of published security vulnerabilities which can be used by hackers has risen as well. In 2017, we witnessed a 51% jump from the year before, following a growing trend of reported CVEs across the software industry.  

Under ideal conditions, an organization will have in place a Software Composition Analysis tool that will track their open source usage and notify them when new vulnerabilities are found in the components that they are using in their software.   

The challenge for organizations is to keep up with the increasing workload of alerts, adding more pressure to an overworked crew as it is.

According to our survey, developers are currently investing 15 hours a month on average to deal with open source vulnerabilities. This includes researching the vulnerability, sending it to other team members or managers for care or advice, and assessing how it impacts the security of their application. Interestingly though, the respondents claimed that they only spent an average of 3.8 hours on the actual remediations. This time spent to remediation ratio would imply that developers’ time is being inefficiently used and that they lack the necessary information for decision making on where to start.  

Digging a little bit deeper in the survey, developers responded that they do not have an accepted method for prioritizing which vulnerabilities need to be on top of the to-do list. The majority stated that they were basing their decisions on a perception of risk to their product, whether it be from the criticality score of the vulnerability, how often it appeared in their software, or on how readily available a fix was to implement.  

What was clear from their answers was that they were making decisions without a full picture of how a vulnerability was directly impacting the security of their product and whether or not it was worthy of their valuable attention.

How do we assess a vulnerability?

Just because a vulnerability is rated as critical does not mean that it should be a top concern. It is easy to look at a vulnerability’s CVSS rating and determine that one is riskier to us than another.  

Without denying the legitimacy of a CVSS number, the potential damage that could be caused by a known vulnerability in an open source component may not be the correct factor in deciding which vulnerabilities needed to be on the shortlist for remediations.  

Instead, it can be argued that the most important factor to consider when dealting with a never-ending list of security alerts is to determine whether a vulnerability actually has a direct impact on a product in a way that can leave it at risk of exploitation.  

When a developer chooses a specific open source component for their software from a resource such as GitHub, they pick one that provides them with the desired feature. They may create an API to access the specific functionality and have their product make calls to it for the intended features. A functionality that is receiving these calls is considered to be effective. However, mixed into the component are other functionalities, that are essentially along for the ride. These functionalities are considered to be ineffective.

Our research into Java components has found that only 30% of the vulnerable functionalities are actually effective. In later observations during our beta with customers, the percentage was even closer to 15%.

These findings have significant implications for how we think about vulnerabilities impacting our products, and how we approach prioritization in vulnerability management, helping us to make better decisions. If a component shows up in an alert as vulnerable because it contains a vulnerable functionality, it is well worth the time to check if it is, in fact, being used by the product in the first place. Nobody wants to have to replace and reconfigure a component unnecessarily. Leaving an alert unanswered is also not ideal, but would unfortunately seem to be a common occurrence.  

Utilizing automated tools for greater visibility

Given the sheer number of security alerts, developers would be hard pressed to research each and every vulnerable component to understand whether or not they are effective. Imagine sending them off on a hunt through the dependency trees, searching for the offending functionality.

Just as keeping track of open source usage manually is a Sisyphean task, so is carrying out manual trace analysis for a vulnerable component to check how it impacts a project. This is where automated tools can come into play to save significant amounts of time.

Automated tools that perform effective usage analysis can do that deep dive for the developer, providing them with a definitive visualization of which vulnerabilities are effective, and which are not.  

Moreover, when an effective vulnerability is identified, it can point developers right to the spot where the vulnerable code is in the product, saving time on the hunt which allows them to get down to their remediation.   

Security teams are overworked and understaffed, so harnessing the power of automation is really the only viable option for moving forward, allowing developers to work more efficiently and spend more of their time on actually developing new software.

Rami Sass, CEO and Co-Founder of WhiteSource  

• We've also highlighted the best open source software