Used by developers around the world, open source components comprise 60%-80% (and likely more) of the codebase in modern applications. Open source components speed the development of proprietary applications, save money, and help organizations stay on the cutting edge of technology development.
Despite the widespread adoption of open source components, myths persist about its usage. The following are the top three concerns associated with open source use.
Myth 1: Open Source Is Not Secure
For as long as there’s been open source, people have been questioning whether it’s as secure as proprietary software. Those who doubt the security of open source components claim that if you don’t know who’s responsible for managing the project and reviewing the code, how can you trust them to do it right?
Open source code is as secure as proprietary software. The difference is because the source code is open, you can verify that it is secure and even submit a fix to the project maintainer if necessary. Over time, open source projects tend to become more secure as developers refine a project’s code. With proprietary software, you can’t examine the source code, so you must trust that the vendor has taken all of the right measures to eliminate security vulnerabilities.
Open source projects also tend to be more transparent than proprietary offerings. Security vulnerabilities, most of which are published with a fix, are posted publicly. The one caveat here is that unlike proprietary software that will push an update to fix a critical security issue, users of open source components are responsible for monitoring and updating their open source code. The good news is that software composition analysis tools (SCA) are designed to answer this very concern, giving full detection and remediation solutions for open source components.
Myth 2: Open Source Code Is a Legal Liability
Some worry that open source licenses automatically put your organization’s proprietary source code at risk simply by using open source components. Others argue that the legal fine print of open source licenses is so complex and varied that license infringement claims leading to legal action is inevitable.
While it is true that there is a wide range of open source licenses – there were more than 200 open source licenses at last count – not all of them require you to make your derivative code public. Much of the concern around these types of claims involve copyleft licenses like GNU’s General Public License, which are more restrictive. Most open source components, however, have permissive licenses that protect derivative proprietary code. In fact, permissive licenses are now far more common, making up 76% of open source licenses in 2020.
Managing the number and complexity of licenses is a different matter though. Each open source component has its own license with terms and conditions that you must comply with. To make matters more complicated, components may have dependencies with different – and sometimes conflicting – licenses.
You can avoid fears over license compliance and non-compatibility issues by using a SCA tool to detect issues early in the software development life cycle (SDLC). With an SCA tool, you can set organizational policies that determine which licenses are allowed, even failing the build for non-compatible licenses, thus preventing more restrictive licenses from even entering your code base. An SCA solution can also handle all the attribution reporting requirements of the many open source licenses in your code base, so you can be sure you are fulfilling all the legal requirements of your open source licenses.
Myth 3: Open Source Is Difficult to Manage
One refrain we hear a lot is that managing open source usage is difficult. It’s next to impossible to get all teams on the same page, and remediating vulnerabilities takes too much time.
There is some truth in this myth. For open source usage to be effective and safe, everyone needs to be on the same page. Managing open source use across the organization requires a consistent set of policies be put in place surrounding license management and vulnerability detection. This can be difficult to achieve when seperate teams handle their open source usage differently. Furthermore, manually tracking open source components, licenses, and security vulnerabilities is an exercise in futility.
Thankfully, these very real concerns can be easily rectified using an automated SCA solution. SCA tools create and enforce consistent open source policies across the enterprise. These policies should be highly customizable to meet your individual organization’s needs. For example, you could have a policy in place that prohibits certain licenses, or you might exclude developers from bringing in open source libraries with high severity vulnerabilities.
In addition to having robust policies, a good SCA solution is one that cuts down on the noise generated by open source security vulnerabilities. Your SCA solution should guarantee zero false positives and identify whether your code actually calls the library with the known security vulnerability. When a security vulnerability that impacts your code is found, your solution should be able to prioritize it based on severity and also offer remediation advice.
A good SCA tool should take the guesswork out of managing your open source both through robust policies that can be implemented enterprise-wide and with the identification, prioritization, and remediation of security vulnerabilities.
Concerns Will Always Exist, but So Will Solutions
The advantages gained by using open source components far outweigh the disadvantages. And let’s be honest, open source isn’t going away any time soon. In this age of Agile development, companies have no choice but to use open source to meet development timelines and market demands.
Despite the concerns surrounding open source use, there are ways to successfully mitigate the associated risks. Not only are SCA tools powerful, but they make managing open source components simple.
If there is one piece of wisdom to impart, it is this: Organizations that wish to harness the power of open source are wise to proactively minimize its inherent risks by using a tool like software composition analysis than to hope nothing goes wrong. Turning a blind eye is a surefire way to ensure something will go wrong.