Open-Source Security in 2020: Myths and Facts

Open-source software isn’t a completely chaotic and breached wasteland of vulnerabilities. It’s a global effort to make the development lifecycle faster.

• By Gilad David Maayan
• Feb 10, 2020

Open-source components are publicly-made codebases. Some are created and maintained by experienced developers and companies, while others are created by beginners. Open-source components are often used in enterprise software, for the purpose of reducing development time. However, the security aspect of these components isn’t always clear.

In this article, you’ll learn what software security is, including key aspects that can impact security. You’ll also learn four open source security myths and facts.

What is Open-Source Software?

Open-source software is software with publicly accessible code. It is generally freely available for use and developed and maintained through community collaboration. The most commonly known example of open-source software is Linux, but many applications and systems use open-source components.

The difference between open-source software and proprietary software is reflected in its licensing, liability, and cost.

• Licensing—There are over 1,400 open-source licenses that software can fall under with a variety of stipulations restricting or permitting use. Many of these licenses specify that software can only be included in other open-source or non-profit projects.
• Liability—Open-source software is used at your own risk. Creators and maintainers are not liable for misconfigurations and are not held to service level agreements. Likewise, support can be dropped at any time.
• Cost—Open-source software is typically free to use, provided you do not need support or additional features. However, these cost savings are partially offset by the time and effort it takes to maintain open-source components.

Open-Source Security Myths and Facts

Myth: Open-Source is Not Secure

Although it is now less of a concern for many developers and development teams, many non-technical staff still worry about using open-source. The primary concern is that a lack of official management in open-source leads to security issues. Another concern is based on the idea that developers might intentionally include vulnerabilities to be exploited later.

Fact: The security of open-source depends on how it is used and managed. It is not inherently less secure than proprietary software.

Frequently, those worried about open-source security simply do not have the tools to properly detect vulnerabilities. Instead, they are left with poorly managed code reviews to ensure security. Others are concerned that the lack of official support creates too great of a security burden for organizations.

One valid concern about open-source security is the public nature of vulnerabilities. When vulnerabilities are discovered in open-source software, these flaws are made public and can be easily exploited by hackers. However, this risk can be negated with monitoring tools that alert you when vulnerabilities or patches are made public.

Myth: Community Oversight is a Double-Edged Sword

The community nature of open-source software creates opportunities for hackers to slip in malicious code that can be exploited at will. Since many open-source components are widely used, many attack opportunities can be created by a single malicious vulnerability. Additionally, since vulnerabilities are made public, you have no way of protecting yourself against hackers.

Fact: Open-source contributions are reviewed by project maintainers and community members before inclusion. Vulnerabilities are made public to both you and hackers.

It is unlikely that open-source would intentionally include vulnerabilities. For malicious code to be included, the community and maintainer would have to be part of the plot to include it. Additionally, while the public nature of vulnerabilities does put you and hackers on even ground it doesn’t necessarily increase your risk. Vulnerabilities are typically made public after a patch has been developed. You can secure your systems when or sometimes before the vulnerability is announced.

Myth: Externally Written Code is Riskier

Externally written code isn’t subject to the same standards and policies that internally written code is. Since it is written by multiple, unmanaged parties, code is likely to be sloppy and poor quality in comparison.

Fact: There is no universal standard that developers follow and the quality of a product will vary no matter who makes it.

If there are certain standards you want to require for your software, you can employ these standards when choosing which open-source components to include. Some projects are haphazardly written and maintained by amateurs. However, some projects are developed and maintained by developers that might have more experience than your own, including software by Linux or Kubernetes.

Since open-source projects are transparent, nothing is stopping you from verifying the quality and standards of a project. You also have the option of modifying an open-source project to meet your standards, effectively moving code from external to internal development.

Myth: Open-Source is Difficult to Manage

It is impossible to track open-source components once included in your software and systems. Maintenance is difficult and time-consuming, and you have no control over licensing.

Fact: Open-source components can be difficult to track and manage if you do it in a disordered way. This is true for any components you include.

If you set policies and guidelines for the inclusion of open-source from the start, management is relatively straightforward. You can create policies explicitly stating which licenses or types of open-source are acceptable to include. You can also specify what needs to happen when components are included. There is no reason why open-source policies should be treated any differently than any other standards you hold your teams to.

Taking advantage of software composition analysis tools can also make the process of tracking and maintaining components easier. These tools create an inventory of your open-source components, including versions and where components are used. SCA tools then monitor vulnerability data sources and alert you when vulnerabilities or patches are made public.

Open-source software isn’t a completely chaotic and breached wasteland of vulnerabilities. Rather, it’s a global effort to make the development lifecycle faster. That doesn’t mean you need to give up on security. You can use vulnerability scanners to keep track of your components and ensure your codebase is kept secure at all times. You can also shift security to the left, and introduce security tests throughout the entire development lifecycle.