Software developers generally spend an inordinate amount of time trying to address open source vulnerabilities, largely because there are no standard practices and developer-focused tools to assist them.
That's according to the recently published WhiteSource State of Open Source Vulnerability Management Report, which is based on a survey of 650 developers from the US and Europe who use open source components regularly as a matter of policy.
The report also includes data from various data sources such as the United States government repository of standards-based vulnerability management data, the National Vulnerability Database (NVD); as well as security advisors, peer-reviewed vulnerability databases, and popular open source issue trackers.
According to Rami Sass, CEO and co-founder of WhiteSource, while the open source community is doing a good job at identifying vulnerabilities in open source projects, users are unable to fully benefit from their efforts because information about vulnerabilities is not published in one centralised location. Instead, it is scattered across hundreds of resources which are often badly indexed and therefore difficult to search.
XHead = Time wasted
The survey found that on average, developers spend about 15 hours every month addressing open source vulnerabilities - but a sizeable number (over 40%), spend between 20 and 60 hours per month involved in reviewing, discussing, addressing and remediating vulnerabilities. These efforts come at a huge cost in terms of time wasted - and the cost is even higher when one considers that it is the more experienced developers who are usually the ones tasked with remediating open source vulnerabilities.
When asked what they do when a vulnerability is discovered, there were no clear answers - a reflection, Sass says, of the fact that there are no standard practices to deal with the issue.
At the same time, the report notes that there was a significant rise in the number of open source vulnerabilities in 2017, up by 51% to reach almost 3 500. This trend continued into 2018.
Not a weakness of open source
However, Sass maintains that this does not indicate a weakness in open source. Rather, he believes, it's an indication of the benefits of open source: because of the software development community's focus on open source security, there is 'an army' of researchers analysing open source projects for vulnerabilities, as well as a quick turnaround for the development of fixes.
In fact, the WhiteSource report notes that 97% of all reported vulnerabilities have at least one suggested fix in the open source community, with security updates usually published within days of the publication of a vulnerability.
Nevertheless, the report notes that the majority of disclosed open source vulnerabilities are found in a limited number of projects - the most popular ones. Sass believes that rather than this being an indication of poor security standards, it can be attributed to the fact that there are far more 'eyeballs' on the more popular projects, making the detection and reporting of vulnerabilities more likely.
Nevertheless, the fact remains that nearly one third of the top 100 open source projects have at least one reported vulnerability, and vulnerable open source projects are likely to contain an average of eight.
XHead = 10 most vulnerable
According to the WhiteSource report, the top 10 most vulnerable open source projects, based on the number of vulnerabilities are:
- Mozilla Firefox (1470)
- Linux (1249)
- Chromium (602)
- Wireshark (549)
- Oracle Java SE (531)
- PHP (486); Moodle (451)
- ImageMagick (415)
- FFmpeg (281)
- WordPress (245).
The most vulnerable programming language, by far, is C/C++, with an overwhelming 41% of all vulnerabilities reported. Next on the list is PHP (17%), followed by Java (8%), JavaScript (7%), Python (6%), Ruby (4%) and C# (1%).
According to Sass, while the open source community is doing a good job at securing open source projects, users are unable to fully benefit from their efforts because information about vulnerabilities is not published in one centralised location. Instead, it is scattered across hundreds of resources which are often badly indexed and therefore difficult to search.
"Although the high number of open source vulnerabilities, including the most popular projects, might seem overwhelming, learning the way that the community manages open source security is a step in the right direction," he says.
"The next step is accepting that open source security management comes with a different set of rules, tools and practices than securing commercial or proprietary components. Sticking with the same vulnerability management programs and tools won't help with open source security management.
"Adopting an open source security policy that addresses these differences and incorporating the right technologies to automate their management will help security and development teams face the unique challenges of open source vulnerabilities head-on, allowing them to get back to the business of building great software," Sass concludes.
Share