Open source usage has become a mainstream practice — it’s impossible to keep up with today’s pace of software production without it. The rise in open source usage has led to a dramatic rise in open source vulnerabilities, demanding that development teams address the rapidly evolving issue of open source security.
The State of Open Source Vulnerability Management drills down into the deeper layers of open source management. Surveying over 650 developers and collecting data from the NVD, security advisories, peer-reviewed vulnerability databases, and popular open source issue trackers, this report brings the latest in open source security management. Our mission is to determine where we are as an industry to know where we can go in years to come.
The number of disclosed open source vulnerabilities skyrocketed in 2017, reaching almost 3,500 reported vulnerabilities.
According to the WhiteSource database, aggregated from the NVD, security advisories, peer-reviewed vulnerability databases, and popular open source issue trackers, the number of disclosed open source software vulnerabilities in 2017 rose by over 50% as compared to 2016. We can see this trend continues in 2018.
This can be attributed to the software development community’s focus on open source security following the widespread adoption of open source components and heightened awareness of security vulnerabilities due to publicized data breaches.
WhiteSource conducted a survey encompassing 650 developers from the US and Western Europe, asking about their practices and the challenges of open source usage.
According to survey results, only a negligible percentage of developers do not use open source components, probably as a matter of company policy. The developers that use open source, rely on them regularly.
The risks are even more severe, since the majority of disclosed open source software vulnerabilities lie in a limited number of projects – the most popular ones!
The more popular an open source project is, the larger its community and the more ‘eyeballs’ it garners from security researchers. With more contributors looking at it, more security and quality issues are discovered and made public every month.
According to WhiteSource’s database, 7.5% of all open source projects are vulnerable. Of the 100 most popular projects, 32% are vulnerable.
While one vulnerability is enough to put multiple libraries at risk, vulnerable open source projects contain 8 vulnerabilities on average.
The list of top 10 open source projects with the highest number of known open source vulnerabilities includes projects we are all familiar with and many of our products depend on.
It’s no coincidence that the majority of these projects are internet facing front-end components with large attack surfaces that are very exposed, making them relatively easy to exploit and therefore attracting a lot of focus.
Another interesting fact here is that there are commercial companies behind most of these projects. Remember that a high number of reported vulnerabilities usually implies that a project is properly maintained by its community, and not an indication of poor security standards.
|Open Source Projects||# of vulnerabilties|
|Oracle Java SE||531|
|Language||% of vulnerabilities|
The rise in security awareness also led to a sharp boost in the number of suggested fixes offered by the community, usually published
within days of the release date.
The rise in open source vulnerabilities has not gone unnoticed by developers. Our survey clearly shows that developers have come to consider open source security vulnerabilities as their #1 challenge when using open source.
26% of developers rated security vulnerabilities as the top challenge posed by open source components. Open source software vulnerabilities were ranked above integration, functionality, licensing and selection. Larger organizations, in particular, are more concerned with open source security.
This concern has become a costly issue, with developers spending almost 15 hours each month dealing with open source vulnerabilities (e.g., reviewing, discussing, addressing and remediating).
The cost goes even higher when we consider that the more experienced developers are usually the ones tasked with remediating open source vulnerabilities.
The WhiteSource survey also shows that 15 hours per month of developers’ time goes into addressing open source security vulnerabilities, as compared with only 3.8 hours monthly for their actual remediation.
The absence of standard practices became apparent when developers were asked what they do when a vulnerability is discovered, and provided numerous answers with no clear practice.
The lack of set practices when attending to newly discovered vulnerabilities explains the inefficient use of time when addressing open source vulnerabilities.
Inefficient remediation practices for security vulnerabilities is becoming a prime concern considering security teams get overwhelmed with alerts on a daily basis.
Top industry experts agree that attempting to solve every single issue is impossible, and that prioritization is key to efficient open source vulnerability management.
Perfect security is impossible. Zero risk is impossible. We must bring continuous risk and trust-based assessment and prioritization of application vulnerabilities to DevSecOps. In a futile attempt to remove all possible vulnerabilities from applications, we are slowing developers down and wasting their time chasing issues that aren’t real (false positives) or addressing lower-risk vulnerabilities that are real, but not directly or easily exploitable.
Survey results show that developers lack standardized best practices for prioritizing open source vulnerabilities.
Results also indicate that developers often look to the most readily available data when prioritizing remediation, like the criticality of an application or the availability of a fix. However, developers tend to prioritize based on available data and not necessarily the correct one.
In the race against hackers, time is of the essence. Especially when it comes to open source vulnerabilities where data is public.
Therefore, lack of vulnerability prioritization leads to inefficient use of resources, when developers are investing time on the “wrong” vulnerabilities.
A new approach to prioritizing open source vulnerabilities should be based on the impact on the product’s security.
A vulnerable functionality does not necessarily make a project vulnerable, since the proprietary code may not be making calls to that functionality (i.e. making it ineffective).
Determining whether a vulnerability poses an actual risk by understanding its effectiveness, can save security and development teams precious time.
After testing 2,000 Java applications, WhiteSource found that 72% of all vulnerabilities detected in these applications were deemed ineffective.
Analyzing effective vs. ineffective vulnerabilities demonstrates how powerful prioritization based on effectiveness is. Data proves that the number of open source vulnerabilities alerts can be reduced by 70%.
Based on the data collected in our survey, this can be translated to saving 10.5 hours per month per each developer (70% of 15 monthly hours).
Organizations that adopt prioritization practices can salvage precious development time and improve the security of their products with quicker remediation of critical issues.
The volume of ineffective open source vulnerabilities found shows that the time and effort organizations currently invest in research and remediation of open source vulnerabilities can be greatly reduced.
The Effective Usage Analysis technology helped development teams save time by locating and focusing their resources on the effective vulnerabilities that required immediate attention. Team leaders and managers testified that the new technology:
The best thing about this new technology is being able to prioritize which vulnerabilities need to be remediated first. It’s been easier tackling the vulnerabilities in our products with a technology that is so easy and scalable.
After seeing the dramatic results of our beta testing, we have no doubt that implementing Effective Usage Analysis on our entire code will be a breakthrough in both reducing effort and improving our results when dealing with open source security vulnerabilities.
Effective Usage Analysis gives us the added value of faster remediation, with trace analysis that pinpoints the exact location of vulnerable dependencies. This new capability enables us to significantly cut down on the time our developers spend dealing with open source vulnerability alerts.
WhiteSource’s vision is to empower businesses to develop better software, by securing and managing the open source components in their software.
A trusted leader in Software Composition Analysis, WhiteSource helps industry giants like Microsoft, IBM, Comcast and hundreds more to harness the power of open source with their continuous open source security and license compliance management solution.