10 Mistakes to Avoid to Make Open Source More Secure

Open source is becoming more popular in the enterprise. But so are open-source vulnerabilities. Here is how you can prevent open source-related mishaps in 2016.

Most of the open-source components you use come “as is,” without support agreements. Without a vendor pushing out patches, it’s up to your organization to identify, track and fix any open-source vulnerabilities in your applications and containers. And with modern code bases comprising tens of millions of lines of code, this is no easy feat—especially with manual methods.

In 2015, NIST’s National Vulnerability Database (NVD) reported more than 2,300 new vulnerabilities in open-source components. While this is down from the OpenSSL bug hunting frenzy of 2014, it still represents over six new vulnerabilities each day of the year. Organizations need visibility into the open source they use, and be able to map those to the ever-changing threat space to avoid leaving easily exploitable vulnerabilities unpatched.

Today, 95 percent of mission-critical apps contain open-source components and 98 percent of companies are using open-source software they don’t know about. And more than 4,000 new open-source vulnerabilities are reported every year. This is only projected to grow year over year, but the time-to-market advantages and ready-made functionality from open source will continue to drive adoption.

The growing corporate embrace of open source has, in turn, spurred the growth of open-source projects. Sixty-four percent of companies currently participate in open-source projects, and some of these have large, active communities. Others are one- or two-person projects. If you’re relying on critical functionality, make sure you are including operational risk in your open-source assessment.

Static and dynamic analysis tools are useful for identifying common security bugs in the code you write. However, they’re incapable of finding vulnerabilities in open-source components, even those vulnerabilities that have been previously disclosed. Further, they provide a snapshot of the security of an application. So, use these tools, but recognize their limitations. What is more effective is automated monitoring software that can continuously track for known vulnerabilities and alert you when they are found, so you always know your code.

Containers enable quick assembly and reliable deployment of applications. The layered architecture allows rapid reuse of base images for new applications. However, open source code within containers comes with the same potential challenges as it does in any other application. Only with visibility into the open source code in your applications and containers can you have the control you need to manage that code.

The ever-connected nature of devices brings new security challenges for device makers and enterprises. Baby monitors, smart doorbells and children’s toys have already been compromised. Those running on outdated versions of Linux and Android can provide a gateway to an entire home or corporate network. Updating vulnerable components may require users to “pull” patches for devices without automatic updates. Security needs to be an integral part of each Internet of things (IoT) device.

Your organization might be in control of in-house development with open source, but what about your suppliers and vendors? For example, the average modern car includes more than 100 million lines of code, much of it open source, from multiple levels of suppliers. If your suppliers aren’t providing you with a software bill of materials, you can’t protect yourself—and your customers—from vulnerabilities.

Is your organization courting intellectual property, licensing and legal risks by violating open-source licensing terms? Uncontrolled use of open source can introduce code issued under licenses that don’t comply with corporate policies, or that could put your own IP at risk.

Without proper visibility into the open-source software in your organization’s code base, you could be blindsided by vulnerabilities discovered months or even years after they originate. For example, ShellShock was present in Bash for more than 20 years prior to its discovery by security researchers, and Heartbleed was present in OpenSSL for two years. Applications using those components were tested thousands of times during those years.