Open-source is increasingly prevalent, either as components in software or as entire tools and toolchains.
It has become a vital part of DevOps and cloud-native environments and is at the root of many servers and systems.
This frequency should make minimizing the risks of using open-source a serious consideration for any organization.
In this article, you’ll learn some of the most common risks of open-source inclusion.
You’ll also learn some best practices for minimizing your risk and ensuring that you can continue to use open-source safely.
Common Open-Source Risks
Understanding the risks that come with open-source use is the first step to securing your components and systems.
Risks are more than just individual vulnerabilities, although these issues are also important.
Community Nature
The community nature of open-source opens you to risks associated with project abandonment.
Open-source maintainers and contributors are typically working voluntarily and open-source projects are not their primary responsibility.
If these volunteers lose interest in a project or are otherwise unable to contribute, project development may suddenly stop or stall.
This leaves you responsible for all future maintenance, vulnerability fixes, and advancement.
Intellectual property infringement is another risk that stems from community sourcing.
Although project maintainers have control over what code gets inserted into a project, they don’t necessarily know whether or not code contributed by others is proprietary.
Likewise, if a project was started for personal use, the originator may have decided to ignore licensing. Or, they may have used code that was only available for personal use.
If you include these components and later find that proprietary code is included, you could be held liable.
Exploits are Public Knowledge
Open-source vulnerabilities are made public knowledge, typically 30 to 90 days after a vulnerability is discovered.
Ideally, this gives communities and users enough time to develop a patch and apply it.
However, if you do not patch during this time, your systems will remain vulnerable and an easy target.
It is common practice for hackers to take publicly available vulnerability information and seek out organizations that are behind on patching.
This information tells attackers exactly how your systems are vulnerable and even how to perform an attack, making their job easy.
Difficulty Tracking Use
The widespread use of open-source means you are likely to have components in most of your applications and tools.
This is true whether or not you’re aware of it. You can read the documentation of tools and applications you use to see what’s included.
However, this information isn’t always easy to find and can be difficult to act on.
In your own development projects, you may have more control over what dependencies are included.
Unfortunately, it’s common that only partial components or code snippets are used, which are almost impossible to track.
Additionally, your teams may use multiple versions of a single component, making tracking and updating more complex.
Inclusion of Vulnerabilities
Copying open-source code or bits of code without understanding what’s being copied is likely to introduce vulnerabilities. Unfortunately, libraries and tooling are often included in a black-box fashion, with minimal understanding of how items function.
This is especially problematic when only a portion of code is taken. Unless you understand exactly how code functions it is difficult to tell whether it includes vulnerabilities.
It could also be that vulnerabilities in the copied code are addressed in later lines or accounted for by other functions.
By only copying a portion of the code, you’ve unintentionally excluded these fixes.
Best Practices for Managing Open-Source Vulnerabilities
The following best practices can help you manage risks created by the inclusion of open-source applications and code.
Monitor Vulnerability Feeds and Databases
Maintainers of open-source projects typically don’t notify users of vulnerability issues. Due to this, it is your responsibility to monitor for patches and to get vulnerability information from other sources. There are a variety of sources to choose from including government and independently managed databases.Â
These sources can provide real-time information and typically include details about vulnerable systems and remediation steps.
Whichever sources you choose, make sure to monitor both official and community feeds. If you don’t you are likely to miss key vulnerabilities. For example,
JavaScript vulnerabilities are less likely to be reported to official databases.
Good sources to start with include:
- National Vulnerability Database (NVD)
- Open Web Application Security Project (OWASP)
- The community feeds of your components
Keep Components Up-to-Date
You need to monitor any open-source components you use and ensure that everything remains up-to-date. The easiest way to do this is with Software Composition Analysis (SCA) tools.
SCA tools can inventory components, scan for updates and patches, and alert you when components are out-of-date.
These tools typically incorporate or can incorporate the feeds you are already watching.
Unlike with proprietary software, updates will not be pushed to you so it’s your responsibility to pull fixes in.
Additionally, make sure to apply these patches feeds as soon as possible. A number of very public breaches have been caused by vulnerabilities that had a patch which the organization didn’t apply. For example, the Equifax breach.
Minimize Your Dependencies
When deciding which open-source components to include in your systems, try to minimize your dependencies as much as possible.
If you are using the same dependency in multiple projects, try to use the same version.
This makes it easier for you to keep components up-to-date and can minimize compatibility issues.
When using full tools and applications, choose ones that are well maintained with active and reliable communities.
Tools with less support are more likely to have undiscovered or unpatched issues. You should also try to use tools that do not rely on excessive dependencies.
Each dependency adds risks and may be a sign of poor product quality, particularly if libraries are used for easy-to-code functionalities.
Conclusion
Open-source applications and code can be hugely beneficial to organizations and individuals, provided you use it carefully.
When using open-source, there are no service level agreements or liability obligations to fall back on.
Instead, ensuring that your components are updated and properly secured is up to you.
Hopefully, this article helped you better understand the most common risks faced when using open-source applications and code.
Being mindful of these issues and applying the best practices introduced here should help you minimize your risks.
Also Read: Top 5 Best Open Source Security Projects That Promote Online Privacy & Protect Your Identity
