State of Software Security: Open Source Edition – Key Takeaways for Developers

The popularity of open source libraries isn’t dwindling anytime soon. They’re critical for developer functionality, allowing teams of developers like yours to work faster so they can meet tight deadlines they face on the regular.

But some developers may not fully understand the risks that come from using open source libraries, just like the risks we found in State of Software Security: Open Source Edition. We took a look at open source libraries and studied reports from 85,000 applications, which included 351,000 unique external libraries. The guide, which delves into the prevalence of open source libraries and how vulnerable they are, sheds light on just how much risk is carried in open source code. Here are some key takeaways.

PHP is a problem

When we broke down the data, we found that the languages with the most open source risk include JavaScript, Ruby, and PHP – with PHP taking the cake in most instances. In fact, the numbers highlighted a glaring problem with this programming language: when you include any given PHP library, the chance of introducing a security flaw along with that library is greater than 50 percent.

​

And when it comes to the most worrisome vulnerabilities, PHP still stands out. We found that nearly half (more than 40 percent) of PHP libraries had Cross-Site Scripting (XSS) flaws, and that Authentication and Broken Access Control vulnerabilities trailed closely behind.

We also examined how organizations prioritize the remediation of their flaws based on the availability of public proof-of-concept (PoC) exploits, and we found that over one-fifth of open source libraries have such an exploit. PHP once again stole the spotlight as the top offender, with 27 percent of flawed PHP libraries showing published exploit code. While we can’t say for sure why these numbers are higher, this may be due to the usage of PHP in web server applications, which is a focus for cyberattackers.

Most flaws are from transitive dependencies

It was important that we peeled back the layers to look at risk-laden facets of open source libraries which are not always obvious to developers on your team. Enter transitive dependencies. While not explicitly introduced during the coding process, these dependencies are often carried over by components within open source libraries and can come with hidden debt that increases workload – as well as costs – down the road.

Our data showed that 71 percent of applications have a vulnerability in an open source library upon initial scan, with 47 percent of the flaws being transitive. PHP and Ruby are top offenders within applications that have transitive dependencies, though JavaScript takes the lead at 87 percent. The numbers are concerning, especially considering that flawed libraries are used more often than unflawed libraries, and transitive dependencies are common.

This presents a problem; the further removed they are from the creation of the original code the harder it is to manage these dependencies and know how to fix flaws quickly. Additionally, because of the hidden nature of transitive dependencies, large attack surfaces on applications can catch you off guard.

Most flaws can be fixed with a simple update

There’s good news, too. When it comes to reducing the security risks of open source libraries, our data shows that almost 75 percent of known flaws are fixable. Even better, they’re usually fixable by updating the code with minor revisions or patches, which won’t disrupt a developer’s busy schedule too much.

​

Languages in top OWASP categories delivered reassuring results too – almost 90 percent of Broken Access Control vulnerabilities (the second most common flaw in applications with PoC exploits) are fixable with a published update. We found the same for Cross-Site Scripting at nearly 90 percent, and Broken Authentication came out on top at 96 percent of flaws with available fixes for you and your team to implement.

Renowned computer programmer and sci-fi writer Daniel Keys Moran said it well: “You can have data without information, but you cannot have information without data.” There’s a silver lining to the risk that comes with open source libraries; the more information you arm yourself with, the more efficiently you can shape your DevSecOps program and improve the health of your applications.  

The bottom line is that there are fixes for these issues, and most are minor – suggesting that this problem is one of discovery and tracking, not huge refactoring of code. Work with your security team to make sure you are equipped with the tools you need to identify and remediate open source vulnerabilities.

Read the full State of Software Security: Open Source Edition report here for a full analytical picture of what we uncovered in our latest round of research.