What is open source software?
Many companies and products, 90% by some estimates, use at least one open source component, even if they are unaware of it. Open source software is software whose code is available for public inspection, modification and improvement. Generally, this software is created through community collaboration and is maintained and updated on a voluntary basis.
Open source software can be used under a variety of licenses, depending on what the creators have implemented. Linux operating system, Apache web server, WordPress and Mozilla Firefox are just some of the most commonly used software.
Risks of Using Open Source Software
Due to its community-building and largely unregulated distribution, a variety of risks, including some cybersecurity risks, come with the use of open source software.
1. The vulnerabilities are common knowledge
Vulnerabilities in open source software are made public by the contributors themselves, as well as by organizations such as the Open Web Application Security Project (OWASP) and the National Vulnerability Database (NVD).
If you’re part of the community for a specific project, you often get advance warning before it’s made public to groups like OWASP and NVD, but the same goes for anyone else in the community. This means that if you are lax in maintaining the latest versions or updating components, you put yourself at risk, as vulnerabilities are often identified and exploited by cybercriminals.
2. Lack of security
Open source software does not come with any legal claims or obligations for security, and community support on how to implement it safely may be lacking. Developers responsible for building software are often not security experts and may not understand how to implement best practices.
Although resources like the Top 10 OWASP vulnerabilities are publicly available and intended for open source communities, they do not always provide instructions 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 from package managers without inspection. The black-box nature of these libraries makes it more difficult and time-consuming to identify and fix any vulnerabilities they might inject.
3. Intellectual Property Matters
There are more than 200 types of licenses which can be applied to open source software including Apache, GPL and MIT. Many of these licenses are incompatible with each other, which means that certain components cannot be used together because you must comply with all terms when using open source software. The more components you use, the harder it becomes to track and compare all of the license terms.
Some licenses include “copyleft” clauses that require you to release any software created with covered components as open source, in its entirety. This makes it impossible to use in proprietary software and less attractive for commercial use.
4. No Warranty
Open source software comes with no guarantees as to its security, support or content. Although many projects are supported, they are carried out by volunteers and their development can be abandoned without notice.
Community members generally rate the software for security issues and provide support through open forums, but they are under no obligation to do so and are not responsible for incorrect advice.
Since open source software is created by communities of sometimes anonymous contributors, it is difficult to verify that the code provided is original and not from a third-party source with established intellectual property rights. In concrete terms, this means that if you are using open source software that is found to contain infringing code, you may be held responsible for the violation.
5. Relaxed supervision of integrations
Teams often have insufficient or no review processes when it comes to knowing what open source components are used. Multiple versions of the same component can be used by different teams or developers can ignore feature or license conflicts.
These issues can arise due to a lack of knowledge of security software or features, 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 checks to prevent the use of multiple or incompatible versions, open-source components generally rely on the user to verify correct usage.
6. Operational deficiencies
Using open source components can create a lot of extra work for already time-pressed teams and it’s often not clear who is responsible for this work. You should keep track of which components are used, what version they are, where they are used, and how they might interact with other components in use.
In addition to this, it is necessary to compare licenses and monitor updates and patches as they become available, including the impacts they may have on functionality. If the components used contain unnecessary functionality, they can add complexity to your system without any benefit.
7. Bad Developer Practices
Developers can inadvertently increase risk if they copy paste sections of code from open source software instead of integrating entire components. This makes it impossible to track that code from a license or security perspective.
When collaborating with other team members, developers can transfer components via email rather than through a binary repository manager or shared network location. This method can leave the code vulnerable to manipulation during transfer, allowing the insertion of security holes or malicious functionality.
How to protect yourself and your organization
Use the right tools
The implementation of DevSec teams can help you build security earlier into your SDLC and integrate open source software securely from the start. Security members can more easily assess which components developers want to use and provide advice on mitigating risks or developing fixes.
Automation tools can provide tremendous value for tracking open source components and their status as well as for component assessment. Open source code can be analyzed before and during use through the Dynamic Application Security Testing (DAST) or Static Application Security Testing (SAST) tools.
Create comprehensive policies
Strategies should require consideration of an open source component’s history, such as the density of known issues, the frequency of releases, and the latency between problem identification and patch. It is important to know the strength of the community involved in a project and to anticipate the type of support it may or may not provide.
Policies should dictate acceptable sources and license types and help developers decide whether to use individual components or a complete codebase.
Many businesses benefit from using open source software and there’s no reason why you shouldn’t benefit from it too. However, knowing the risks posed by open-source software—entering the development process—will help you avoid the pitfalls associated with sharing crowd-sourced code. By considering the risks described in this blog and implementing protective strategies, in addition to others necessary to secure your systems, you can help ensure the safe use of open source software.