Report: Open Source Vulnerabilities Rampant in Popular Projects

Open source vulnerabilities rose by nearly 50 percent in 2019 over the previous year, based on a report released Thursday.

Common vulnerabilities rated as high or critical severity were found in all of the most popular open source projects, according to the WhiteSource 2020 annual report, “The State of Open Source Security Vulnerabilities.”

The vulnerability rate is expected to continue rising.

As open source usage continues to grow, so does the number of eyes focused on open source security research. This resulted in a record-breaking number of published open source security vulnerabilities last year, according to the report.

The report covers open source vulnerabilities published in 2019 along with security vulnerabilities in popular programming languages. It also reviews the most common CWEs, or common weakness enumerations, in recent years. It weighs the role of open source vulnerabilities’ scoring and severity, and the types of vulnerabilities found in the most popular open source projects.

The number of disclosed open source software vulnerabilities in 2019 skyrocketed to more than 6,000 reported vulnerabilities, according to the WhiteSource database. WhiteSource aggregated its research results from the National Vulnerability Database (NVD), dozens of security advisories, peer-reviewed vulnerability databases, and popular open source issue trackers.

Researchers attributed this record-breaking increase to the rise in awareness of open source security following the widespread adoption of open source components and the massive growth of the open source community over the past few years. Researchers also saw an impact from media attention directed at recent data breaches.

“The sharp increase in the number of new open source security vulnerabilities published in 2019 means the entire industry, along with the open source community, is paying more attention and investing resources and efforts in discovering, fixing and reporting vulnerabilities in open source components,” said Rhys Arkins, director of product management at WhiteSource.

Key Findings

Open source usage and research continues to proliferate. Along with the growing popularity of open source projects, the number of reported open source vulnerabilities continues to grow.

More than 85 percent of vulnerabilities are published with a fix, but not all fixes are reported in the NVD. Only 84 percent of known open source vulnerabilities eventually appear in the NVD.

The NVD is the U.S. government repository of standards-based vulnerability management data based on the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement and compliance.

Only 29 percent of all open source vulnerabilities reported outside of the NVD eventually are published in it. That finding is based on WhiteSource’s database.

More than 55 percent of reported open source vulnerabilities in 2019 were classified as high or critical severity. This large number impacts on software teams’ ability to prioritize vulnerability remediation.

CWE-79 (cross site scripting), CWE-20 (improper input validation) and CWE-200 (information exposure) are the top three CWEs for Java, JS, php and Python vulnerabilities.

Results No Threat to Reliability

It is unlikely this report will weaken enterprise confidence in open source software, WhiteSource’s Arkins told LinuxInsider. Open source usage has become a standard practice across all industries and verticals. The report should not change that or cause organizations to question the security of open source components.

“On the contrary, the rise in the number of reported open source security vulnerabilities is actually good news,” he said. “It is a result of the growing awareness of the importance of open source security, which brings more and more big tech backing and working hands to poke and prod at open source code and fix vulnerabilities quickly and efficiently.”

Instead of distrusting open source, enterprise now needs to learn how to support the open source community’s efforts, Arkins suggested. Enterprise needs to leverage all of the community’s hard work on reporting open source vulnerabilities to ensure that the open source components they are using are updated and secure.

Predictions for 2020

With the continued increase of both open source usage and security research, the number of reported open source vulnerabilities will keep rising, the 2019 vulnerability report predicts.The open source community increasingly is seeking ways to address the chaos in the open source security process with new initiatives.

One good example is the GitHub Security Lab. It makes it easy for researchers, maintainers and users to report open source vulnerabilities, and it publishes a verified fix in one centralized location, noted Arkin.

GitHub’s embedded disclosure process will encourage open source projects to report vulnerabilities properly, rather than just push a fix.

Having the maintainers themselves report vulnerabilities should lead to higher-quality metadata. That would improve the reporting process for issues like affected versions and fixed-in versions, as opposed to third-party reports of the problem, the researchers noted.

Transformative Years

However, the rosy predictions of the current WhiteSource report may not hold true, suggested Thomas Hatch, CTO of SaltStack, as open source software has undergone a transformation in recent years.

“The nature of OSS has been shifting, and the present state of OSS software is arguably worse than in the past,” he told LinuxInsider. “But instead of looking at OSS as good or bad, we should keep in mind that the way we approach these opportunities changes the nature of how they work.”

Originally, dedicated engineers with religious zeal made open source software. They worked to create the cleanest software they could, with a goal to take over the world with open source, Hatch suggested.

“Over time this shifted to become an arm of corporate development as corporations began to understand how OSS could augment and accelerate their efforts. Today there is an emerging mindset that prioritizes freemium and prototype software causing issues in open source,” he said.

The current state of security in OSS is no surprise given that this attitude is combined with ease of contribution, a culture of constant pull requests, and pressure on developers to hit the merge button, Hatch said.

“As open source continues to shift into the realm of prototype software, these issues will continue to mount. Keep in mind that our acceptance of slapdash corporate software is also on the rise. I think that security issues will continue to grow across the board,” he added.

Most Secure Programming Languages

The WhiteSource report compares how the top seven coding languages stack up with reported open source vulnerabilities in 2019 over previous years.

• C still has the highest percentage of vulnerabilities due to the high volume of code written in this language. But those numbers are trending down as other languages become more popular.
• PHP’s relative number of vulnerabilities has risen significantly with no indication of the same rise in popularity.
• Python still has a relatively low percentage of vulnerabilities. Its popularity in the open source community continues to rise. This could be a result of secure coding practices and not lax security research for Python projects.

Here are the most common CWEs per year from 2014 to 2019 for the seven most popular programming languages.

Most Common Vulnerabilities

The top five CWEs in 2019 have been consistent over the past several years. All are related to information disclosure. A big concern is that the most common CWEs are due to simple errors and imprecise coding. All developers could avoid this issue by sticking to fairly basic coding standards.

This chart shows the top five CWEs.

CWE-352, Cross-Site Request Forgery (CSRF), has emerged in the top 10 CWEs this year. CWE-89, SQL Injection, re-emerged after not appearing as one of the top CWEs since 2015.

This might have resulted from an increase in the volume of open source Web projects developed. It might indicate that Web vulnerabilities are on the rise. Either way, code writers should be aware, suggests the report.

Here are the most common CWEs per year between 2014 and 2019.

Is Severity Scoring at Fault?

The report addresses the reliability of the CVSS (Common Vulnerability Scoring System) score, considering whether the mechanics of scoring may have created a statistical anomaly.

Development teams must prioritize security alerts quickly. The CVSS score is usually the go-to parameter for remediation prioritization. That may have caused the statistically big increase in the number of reported open source vulnerabilities last year, according to the report.

CVSS has been updated several times in the past few years (v2 to v3, and most recently v3.1) in attempts to achieve a measurable, objective standard that helps support all organizations and industries, the report notes. That caused a change in the definition of a “high severity vulnerability.”

The most noticeable change in the update from v2 to v3 was that scores rose substantially. A vulnerability that would have been rated 7.6 under CVSS v2 could have a rating of 9.8 under CVSS v3.0. With CVSS v3.0, teams faced a higher number of high and critical severity vulnerabilities.

“Still missing are the tools to prioritize and address them, or even fully understand the vulnerabilities’ impact on their project,” the report states.

The research team uncovered a disparity in the severity distribution with the new CVSS v3.1 score: 17 percent of the vulnerabilities were critical and only 2 percent were low. That is not a normal distribution.

How can teams prioritize vulnerabilities efficiently when more than 55 percent are high-severity or critical? the report asks.

The Search for Clarity

The shift in classifications is only one of several reasons for the recent rise in the number of high and critical severity CVSS scores, observed WhiteSource’s Arkin. The heightened focus on high and critical issues is another reason.

So is the fact that creating a CVE is a time-consuming process that some prefer to avoid when it comes to lower-severity issues. That explains the imbalance between the number of low severity and high-to-critical severity issues being published, he said.

The security ecosystem continues to evolve. The security research community is working to find an objective severity scoring standard that will help users across all verticals and industries address new challenges. The standards are still being perfected, Arkin pointed out.

“That does not mean that the severity scores are unreliable. It is important to remember that the latest CVSS v3.1 measures severity, and not risks,” he explained.

Organizations must consider the impact of a specific vulnerability on the security of their products based on a number of factors. The process involves more than the severity score, Arkin added.

What’s Needed

The most common CWEs over the past few years, across most top programming languages, resulted from fairly simple coding mistakes, according to Arkin. So development teams must make secure coding a priority. That includes training, as well as using automated tools and processes to detect potential flaws as early as possible in the development process.

Developers, DevOps and security teams face the challenge of addressing long lists of security alerts. The data and insights in the WhiteSource report can help them better understand how to address open source security vulnerabilities efficiently.

“The heightened awareness that we see around open source security means that big tech, along with the open source community, has been investing a lot in open source security,” he said, adding that continued investment will ensure that open source users are kept informed about vulnerabilities.

Looking Forward

These issues occur in practically all of our favorite open source software projects, according to the report. The most important takeaway is that just because popular open source projects have vulnerabilities does not mean they are inherently insecure.

Instead, it means open source users need to be aware of the security risks. That includes making sure they keep dependencies up to date.

“The open source vulnerabilities landscape might seem complex and challenging at first. But there are ways to gain visibility and control over the open source components that make up the products that we release,” the report concludes.

An open source project with vulnerabilities is not inherently insecure, Arkin emphasized. Rather, it probably means that there are many hands working to ensure that it is vulnerability-free. It also means that maintainers are making sure that users have all the information they need.