Open Source Vulnerabilities

Open source software is rapidly gaining popularity with 93 percent of organizations using open source software and 78 percent performing all or part of their business operations on open source platforms, according to the Tenth Annual Future of Open Source Survey.

Statista estimates the revenue of open source software to hit some $70 billion by 2020. These are huge numbers and while open source software provides obvious advantages to organizations, there are some very serious security problems that one should consider before and after implementing an open source solution.

Misconceptions about Open Source Security

Companies often undermine open source security, due to the misconception that you detect and patch proprietary vulnerabilities and open source security vulnerabilities in the same manner. open source security and proprietary code security are quite different and you need to address open source security very differently.

Actually, even the most experienced open source developers are prone to leaving security holes in simple and complex software alike. Furthermore, a good number of organizations rush to adopt open source solutions and reap the benefits of free licensing, overall higher security level, and ever-growing number of enterprise apps and platforms. Nonetheless, many of them lack the internal expertise to work and secure effectively the selected open source software, including often times the firms that develop software themselves.

The very fact that the software is open offers great advantages in terms of customization and tweaking of the source code to fit your specific needs but you should be aware the source code is open for others as well. You definitely need to be sure the source code of each and every open source software you are incorporating into your products is free of any vulnerabilities. This is the only method to avoid exposure of business-critical data as well as unauthorized access to your connected systems.

When using open source components in your software, the primary risk to consider is that Vulnerabilities here are not hidden from public view, but widely distributed. Because popular components can be used across thousands of organizations, the community will publish vulnerabilities on databases like the U.S. government-backed National Vulnerability Database (NVD). This is a good thing since it will allow developers to stay up to date on which components are found to be vulnerable and need to be patched. On the other hand, it gives hackers a free list of exploits without the work of sifting through code themselves. All they have to do now is try the exploit on a range of targets and hope that some percentage of them have been too slow to keep up on the latest vulnerabilities and are left unpatched. This method can lead to multiple targets being exploited and plundered with a single vulnerability that was handed to them on a silver platter.

Open Source Security Mitigation

Analyzing the source code of a complex open source component is a very challenging and time-consuming task. A wise move is to adopt a professional solution that identifies such vulnerabilities at an early stage i.e. before you have committed an open source component to your build. There are a number of solutions such as WhiteSource Solution that provide the means to secure open source components. It is worth a try, especially in the light of continuing security breaches caused by vulnerabilities in open source software.

The latest massive security breach occurred at the US consumer credit reporting agency Equifax in which personally identifiable information (PII) on more than 147 million Americans was stolen. Reportedly, the data security breach occurred due to flaws in an open source server framework, Apache Struts2, used by Equifax. During the past few years, server misconfigurations and security holes, combined with phishing and hacking techniques, caused data leaks of millions of user accounts by large corporations such as JP Morgan Chase, Yahoo, Ebay, Adobe, Target, and AOL to name only the cases where tens of millions of accounts were compromised.

The Heartbleed Bug is exemplary in terms of the importance of open source security and application of tools that provide functionality to find security holes. This bug in the widely used OpenSSL cryptographic software library lived unnoticed for years enabling malicious agents to steal information that should have been protected by the SSL/TLS encryption used to secure the internet.

Solutions such as the one provided by WhiteSource can help by integrating with your CI servers and build tools and repositories that detect all open source components within your software environment. The tool provides real-time alerts concerning vulnerabilities and problematic components, all without the need to scan your code. Instead, they use a form of hashing to identify all the specific components in your inventory in just a matter of minutes. This also means an end to chasing down false positives. Their solution generates complete reports with a single mouse click enabling you to simplify the management of open source components through automated policies. Because their solution is continuously monitoring your inventory, there is never any down time in between scans when a vulnerable component could slip through into your products.

Bottom Line

All in all, open source software has the potential to be more secure than closed source applications, relying on the “thousand eyes” of the community members who pour over the code, searching for vulnerabilities. Nonetheless, you need tools to assess and monitor your open source software for vulnerabilities, preferably in real-time.

You should be aware that open source software is not secure by itself; you need to make every effort to secure it and ensure that every newly added component is also secure. Do not let to be misguided by the popular fallacy that by adopting an open source solution you get immediate security. Opt for a reliable tool that monitors your open source software and systems and helps you implement preventative security measures just on time.

Looking back at the Equifax case, if the company would have had a Software Composition Analysis (SCA) tool, like the one from WhiteSource, that could have detected which open source components they had in their products, then they could have known that they needed to patch the vulnerable version of Apache Struts2. Remember that you can’t patch properly if you don’t know what you have.

Series sponsored by WhiteSource

By Kiril V.Kirilov