Breaking Down Risky Open Source Libraries by Language

You work hard to produce quality applications on tight deadlines, and like every other development team out there, that often means relying on open source code to keep projects on track. Having access to plug-and-go code is invaluable when you’re racing the clock, but the accessibility of open source libraries comes with a caveat: increased risk.

In our recent report, State of Software Security: Open Source Edition, we examined the security of open source libraries by studying data from 85,000 applications – including 351,000 unique external libraries. From the data, we evaluated the prevalence of flaws in open source libraries as well as how vulnerable they are, gaining insight into the risk that you might carry when you use open source code in your software development process.

While we found that a sizeable 70.5 percent of the applications had an open source flaw on initial scan, some of the most interesting drill-down data came from examining flaws in the top 50 open source libraries broken down by language. The results, highlighted in an interactive infographic, were eye-opening about a few languages in particular.

Languages to keep an eye on

As an example, JavaScript had more libraries in use than any other language, and a handful stood out as containing risky flaws. In the charts below — taken from our interactive infographic, which you can view in full here — the lighter blue dots represent libraries that have some flawed versions in use and their placement is relative to the percentage of applications that each specific library is used within. The largest light blue dot hovering around 88 percent represents Lodash, with 401 versions of that library containing a flaw – something to keep in mind when using Lodash in your code.  

​

PHP also raised some alarms as we dug into the data. We found that including any given PHP library in your code increases the chance of introducing a security flaw along with that library by more than 50 percent.

The flaws it carries are dangerous, too. We uncovered that more than 40 percent of PHP libraries contained Cross-Site Scripting (XSS) flaws with Authentication and Broken Access Control vulnerabilities close behind. And as you can see in the chart below, the light blue dot towards the right of the scale represents PHPUnit libraries as a flaw offender, with about 63 versions containing a flaw.

​

One of the more colorful charts in our data represents Ruby, of which we uncovered three library versions in use that are known to have been exploited. Those three versions include:

• Rails: Used in 47 percent of applications written in Ruby, with 337 versions containing a flaw and 133 versions exploited.
• Action Pack: Used in 49 percent of applications written in Ruby, with 343 versions containing a flaw and 85 versions exploited.
• Active Support: Used in 66 percent of applications written in Ruby, with 235 versions containing a flaw and 117 versions exploited in the wild. ­­

​

We found over one-fifth of open source libraries have public proof-of-concept (PoC) exploits, which many organizations use to prioritize treating flaws. Alongside PHP, Ruby has noticeable public proof-of-concept (PoC) exploits for some versions in use – such as Nokogiri with 24 versions, and Rack with 25 versions.

The bottom line is that it’s important to stay on top of the security of your code, including snippets you didn’t write from scratch. Software Composition Analysis (SCA) will help you identify vulnerabilities in open source libraries, while also providing recommendations on version updating so that you can find and fix flaws in your open source code before they become a problem.

Check out the full infographic to see the rest of the data on the top 50 open source libraries broken down by language, and read the full report here to gain more insight.