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. According to the report, this resulted in a record-breaking number of published open-source security vulnerabilities last year.

The report covers open-source vulnerabilities published in 2019 and 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 continue to proliferate. With the growing popularity of open-source projects, the number of reported open-source vulnerabilities also 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 the automation of vulnerability management, security measurement, and compliance.

Only 29 percent of all open-source vulnerabilities reported outside of the NVD are eventually 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 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.”

Arkins suggested that instead of distrusting open source, enterprises need to learn how to support the open source community’s efforts. Enterprises should leverage 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

The 2019 vulnerability report predicts that the number of reported open-source vulnerabilities will keep rising as both open-source usage and security research continue to increase. The open-source community is increasingly seeking new initiatives to address the chaos in the open-source security process.

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.

Hatch 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.

“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, which could be a result of secure coding practices rather than 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, or it might indicate that web vulnerabilities are on the rise. Either way, the report suggests that code writers should be aware.

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 and considers whether the scoring mechanics 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.

The report notes that CVSS has been updated several times in the past few years (v2 to v3, and most recently v3.1) in an attempt to achieve a measurable, objective standard that helps support all organizations and industries. That changed 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.

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

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 two 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

According to Arkin, the most common CWEs over the past few years across most top programming languages resulted from fairly simple coding mistakes. So, development teams must make secure coding a priority. That includes training and 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

According to the report, these issues occur in practically all of our favorite open-source software projects. 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 keeping 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.

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