7 Risks Posed by Open-Source Software and How to Defend Yourself

What is Open-Source Software?

Many businesses and products, 90% by some estimates, use at least one open-source component—even if they aren’t aware of it. Open-source software is software whose code is available for public inspection, modification, and enhancement. Typically, this software is created through community collaboration and is maintained and updated on a volunteer basis.

Open-source software can be used according to a variety of licenses, depending on what the creators have implemented. Linux OS, Apache Web Server, WordPress, and Mozilla Firefox are just a few of the most commonly used software available.

Risks of Using Open-Source Software

Due to its community construction and largely unregulated distribution, a variety of risks—including some cybersecurity risks—come with the use of open-source software.

1. Vulnerabilities are Public Knowledge

Vulnerabilities in open-source software are made public knowledge by contributors themselves, as well as by organisations like the Open Web Application Security Project (OWASP) and the National Vulnerability Database (NVD).

If you are part of the community for a specific project, you often get advanced warning before it is made public to groups like OWASP and NVD, but so does anyone else that is part of the community. This means that if you are lax in maintaining the latest versions or updating components you are leaving yourself open to risks, as vulnerabilities are often identified and exploited by cybercriminals.

2. Lack of Security

Open-source software comes with no claims or legal obligations for security and community support informing you how to implement it securely may be lacking. The developers responsible for creating software are often not security experts and may not understand how to implement best practices.

Although resources like the OWASP Top 10 vulnerabilities list are publicly available and targeted towards open-source communities, they don’t always provide instruction on how to implement security features to protect against these flaws.

Often open-source software includes or requires the use of third-party libraries, pulled in from package managers without inspection. The black-box nature of these libraries makes it more difficult and time-consuming to identify and patch any vulnerabilities they might inject.

3. Intellectual Property Issues

There are over 200 types of licenses that can be applied to open-source software, including Apache, GPL, and MIT. Many of these licenses are incompatible with each other, meaning that certain components cannot be used together since you have to comply with all terms when using open-source software. The more components you use, the more difficult it becomes to track and compare all of the license stipulations.

Some licenses include “copyleft” clauses that require you to release any software created with the covered components as open-source, in its entirety. This makes it impossible to use in proprietary software and less attractive for use in commercial purposes.

4. Lack of Warranty

Open-source software does not come with any warranties as to its security, support, or content. Although many projects are supported, they are done so by volunteers and the development of them can be dropped without notice.

Community members typically evaluate the software for security issues and provide support through open forums but they are not obligated to do so nor are they liable for faulty guidance.

Since open-source software is created by communities of sometimes anonymous contributors, it is difficult to verify that code being contributed is original and not taken from a third-party source with established intellectual property rights. What this means in practice is that if you use open-source software that is found to contain code with infringed rights, you can be held responsible for infringement.

5. Relaxed Integrations Oversight

Teams often have insufficient or non-existant review processes when it comes to which open-source components are being used. Multiple versions of the same component might be used by different teams or developers might be unaware of conflicting functionality or licensing.

These issues can occur due to lack of knowledge of software or security functionality, lack of communication between teams or team members, or insufficient or absent tracking and documentation protocols.

Unlike third-party proprietary software, which has built-in controls to prevent the use of multiple or incompatible versions, open-source components typically rely on the user to verify proper use.

6. Operational Insufficiencies

The use of open-source components can create a lot of additional work for already time-crunched teams and it often isn’t clear who is responsible for this work. You must keep track of what components are used, what version they are, where they’re used, and how they might interact with other components in use.

In addition to this is the need to compare licensing and monitor updates and patches as they are made available, including what impacts they may have on functionality. If components used contain unnecessary functionality they can add complexity to your system with no benefit.

7. Poor Developer Practices

Developers can inadvertently increase risks if they copy-paste sections of code from open-source software instead of integrating whole components. Doing so makes it impossible to track that code from a licensing or security perspective.

When collaborating with other team members, developers might transfer components through email rather than through a binary repository manager or shared network location. This method can leave code vulnerable to manipulation during transfer, allowing the insertion of security flaws or malicious functionality.

How to Protect Yourself and Your Organisation

Use Proper Tools

The implementation of DevSec teams can help you integrate security earlier in your SDLC and integrate open-source software securely from the start. Security members can more easily evaluate components that developers wish to use and provide guidance on mitigating risks or the development of patches.

Automation tools can provide enormous value for tracking open-source components and their status as well as for evaluating components. Open source code can be scanned before and during use through Dynamic Application Security Testing (DAST) or Static Application Security Testing (SAST) tools.

Create Comprehensive Policies

Policies should require consideration of an open-source component’s history, such as the density of known issues, version release frequency, and latency between issue identification and patch. It is important to know how robust the community involved in a project is and anticipate what sort of support it might or might not provide.

Policies need to dictate what sources and license types are acceptable for use and should help developers decide whether to use individual components or an entire codebase.

Conclusion

Many companies benefit from the use of open-source software and there is no reason you shouldn’t benefit as well. However, knowing the risks posed by open-source software — going into the development process — will help you avoid pitfalls associated with sharing crowd-sourced code. By taking into account the risks outlined in this blog and implementing protection strategies, in addition to others as required to secure your systems, you can help ensure the safe use of open-source software.