Top 3 Open Source Risks and How to Beat Them
Table of Contents
In the olden days, organizations were wary of using open source code when developing software products. Their legal teams didn’t want to deal with open source licensing and copyright chaos. Execs looking at the bottom line were extremely averse to the combination of the words “free” and “software” when it came to selling their wares, terrified at the prospect of allowing the general public access to glimpse behind the curtain and see what ingredients went into their secret sauce.
We’ve come a long way since then. Open source software components are a part of practically every development team’s standard practice, and most organizations’ offering to their customers throughout all industries and verticals. The numbers speak for themselves: today, open source software components compromise between 60% to 80% of most organizations’ code base.
Keeping your open source software components risk-free
As much as we love the benefits of using open source software components, they still come with risks. Let’s be honest, proprietary software has its own set of issues, but we’re here to better understand open source risk.
In order to ensure the security, quality, and compliance of the open source components that we use and ultimately, the products that we ship, we must address the risks that come along with open source software usage and the measures that we need to take to avoid them.
Open source components are available on numerous online repositories, and developers have no way of knowing their level of quality or safety. When organizations don’t invest in managing their open source usage, they put themselves at risk, and might end up paying for it down the road when fixing mistakes becomes far more costly.
Open source software usage presents legal, engineering, and security challenges, and when organizations aren’t on top of the quality of the open source components that they are using, they could unknowingly be incorporating vulnerable, risky, unlicensed, and out-of-date components.
1: Open source software security risks
Open source security vulnerabilities are an extremely lucrative opportunity for hackers. Once discovered by the security research community, open source vulnerabilities and the details on how to carry out the exploit are made public to everyone. This provides hackers with all the information that they need in order to carry out an attack. To make matters worse, since open source usage is so widespread, a vulnerability in a popular open source component provides hackers with many potential exploit victims.
This means that hackers are following the open source community closely, and pounce on known security vulnerabilities in popular open source components. If software companies don’t manage their open source usage, unaware of any vulnerable open source libraries in their code, they are at risk of a malicious attack.
Tracking open source software security vulnerabilities and their fixes requires an organization to employ specific tools and processes. Today, known open source vulnerabilities are published across a variety of security advisories and databases, and not in one centralized location. That makes keeping track of known open source vulnerabilities nearly impossible to carry out manually, especially at scale. Locating the patch, fix, or updated version for mitigating the security risk requires a lot of man hours, and can never be completely thorough. If that’s not challenging enough, there is also the pesky issue of dependencies between open source components and libraries.
Once a security vulnerability and its mitigation are published, hackers are most probably planning their attack. That means that finding the risky open source component and its branches in your projects as quickly as possible, should be an organization’s top priority as it is in a race against the hackers.
2: Open source software licensing compliance risks
Every open source software component, along with its dependencies, comes with a license. When we use an open source component in our project, we are agreeing to a set of terms and conditions that we must comply with. This can become murky territory for anyone who is not well versed in the ins and outs of open source licensing.
Getting into the nitty gritty of open source licensing is not for the faint of heart. Did you know that there are over 200 types of open source licenses out there, each with its special, specific, and often confusing terms and conditions?
There’s copy-left, there’s “Anything Goes”, then there’s permissive with strings, and to top it all off, some projects available in open source repositories are missing any type of source license — which means default copyright laws apply. So many licenses, so little time to a sprint, makes it extremely challenging to comply with all the legal requirements.
Businesses that don’t keep track of their open source licenses are playing with fire, since not complying with the terms of open source licenses is extremely risky business, leaving an organization open to a lawsuit or unknowingly relinquishing the exclusive ownership of the proprietary code.
3: Open source software quality risks
While an organization invests many resources in the quality assurance of its proprietary code, it appears many development teams marginalize or overlook checking an open source component’s quality. Obviously, we all want our final product to be stable and consistent under pressure. How can we ensure that the open source components that we are using won’t risk the project’s quality? What qualifies an open source component to be of high quality?
One of the reasons it’s a challenge to ensure that an open source software component does not put the quality of your product at risk is that there are no agreed upon standards for evaluating an open source component’s quality, and the collaborative nature of open source can make it challenging to measure.
Preethi Thomas of Red Hat points out that in open source, “community involvement is voluntary, people’s skills, levels of involvement, and time commitments can vary,” making quality assurance a challenge. Usually, when choosing an open source software component most developers will go with what they know, and if they’re not sure they might ask a friend. Chances are quality won’t be the first thing on their checklist when selecting an open source component.
But if we really want to ensure that we incorporate stable and reliable open source projects — what are some of the things we can look at?
At Mend, the quality of an open source component is rated based on three aspects of an open source component:
- Number of commits, as an indicator of its level of activity.
- How many bugs are fixed in each specific version.
- The amount and severity of open bugs for each specific version.
Automated tools can mitigate open source risks
Open source software components enable us to speed up development and lower costs, freeing us up to create innovative products that give us the competitive edge that we need to stay on top.
In order to maintain that edge, we must address the risks of open source components. In order to mitigate open source risks, we need to track the open source components that we are using, including all their dependencies, while keeping on top of information and updates coming from the open source community.
The best way to ensure we are one step ahead of the risks, without missing a beat, is to incorporate automated tools that continuously track our open source usage and match them up against the most current data about open source components, their vulnerabilities, risks, fixes and updates.
Automated open source management tools allow us to put our ear on the pulse of the open source community, and keep a constant eye on our open source usage, helping us remain open source risk-free.
