The Vexing Problem of Open Source Vulnerabilities

By Community Team

Apple, Samsung, Google, Microsoft, IBM. What do these brands have in common? Besides being some of the biggest brands in the world, all these companies are using open source software in their products and have established their own dedicated open source teams.

This is how influential open source has become. But on the flipside, its vulnerabilities have become equally as pervasive.

The Pervasiveness of Open Source Vulnerabilities

No other example could probably best illustrate the prevalence of open source vulnerabilities more than the Equifax breach of 2017. Because of the vulnerability found in their Apache Struts component, the personal information of close to 150 million U.S., U.K. and Canadian customers were compromised.

Yet even after this disastrous incident, some organisations seemed heedless to the threat that these types of vulnerabilities cause. According to the 2018 Open Source Security and Risk Analysis Report, 8% of the 1,100 codebases audited still contained Apache Struts and of these, a third still contained the Struts vulnerability to which Equifax fell victim.

The report also showed that 78% of the codebases contained at least one unpatched vulnerability, with an average of 64 known vulnerabilities per codebase. In the Internet of Things alone where 77% of the code was found to be open source, there was a whopping average of 677 vulnerabilities per application.

Among the audited codebases, 17% were found to contain a named vulnerability: Poodle was found in 8%, Freak and Drown were found in 5% and even Heartbleed, one of the most publicised of named vulnerabilities was found in 4% of those scanned.

The Real Problem

Open source vulnerabilities in themselves are a serious problem, but what’s even more distressing is that most developers already know many of these vulnerabilities and how to protect themselves from them, but they don’t. Far too often, developers will take open source code carelessly without checking if it has any known vulnerabilities, and only a few apply solutions to track the open source components in their products. Without proper tracking you won’t really know what you have, and you can’t patch for something you don’t know you have.

Among all the possible vulnerabilities there may be in open source code, the ones that pose the greatest threat are known vulnerabilities. These vulnerabilities are listed on the National Vulnerability Database for everyone to peruse, and while this gives developers the information they need to patch their applications, at the same time it also gives hackers the intel they need to target organizations that may be too slow to make proper fixes. This is why it is crucial for developers to check for known vulnerabilities in particular.

The Challenge for Developers and Security Teams

So apart from looking for exploits in the code itself, developers and specifically security teams also need to stay on top of known vulnerabilities. This of course means knowing what open source components are already in your inventory, the security status of each and which contain existing vulnerabilities.

The community has consistently done its job of discovering and reporting vulnerabilities and issuing patches. The National Vulnerability Database continues to be updated and open to all of us. Resources and tools are widely available to assist us in tracking open source components. Let us do our part by utilizing these resources, and having the processes and policies in place to properly manage open source code.