As the use of open source components in commercial software continues to grow, so does the need to manage it well.
With open source components being used in more than 80 percent of commercial software developed today, ALM efforts must be altered to address them. Failing to do so may introduce unnecessary risks. This article outlines the potential risks associated with not managing open source as part of your ALM, and explains how these risks can be easily avoided with proper open source management.
Open source is playing an increased strategic role in today’s enterprises. This requires us to make changes to our ALM efforts. It should not be hard or time-consuming, but it does require some attention. Without this attention, you are taking on several risks.
Here are the top risks you’d want to avoid:
1. Failing to identify and manage open source dependencies
Most open source components rely on other open source components (commonly referred to as dependencies). Those are often missed when documenting open source manually. Ignoring the dependencies your open source components are based upon is equivalent to looking only at the tip of the iceberg.
According to WhiteSource's research, in 91% of software projects some of the open source components imported by developers contained additional dependencies that were brought in by those components. More so, in 65% of the cases, open source components bring with them additional dependencies that are subject to a different license.
WhiteSource Research: in 64% of open source components checked, dependencies had different licenses than the open source components that used them
2. Failing to set open source policy
Your way of doing business, your customers and your technology should all affect your open source policy. Your legal team knows best which licenses should be forbidden and which one should be recommended to your engineers. The engineering team knows best which security vulnerabilities can be introduced (low CVE score) and which ones could be very problematic.
Set a clear policy to your developers based on your company business and development needs. You can also save your development team a lot of precious time if you set up an automated policy plan that will prevent them to checking each components before integrating it.
WhiteSource Research: 27% of companies surveyed do not have a well-defined open source policy
3. Failing to know when the open source policy is violated
Having an open source policy is great, but will not help you much if you do not know when it is violated and rectify the situation.
WhiteSource Research: 91% of companies with well-defined open source policies do not know when they are violated
4. Failing to update open source components for security issues and other bugs
Like any software, open source components may occasionally suffer from security vulnerabilities and bugs. The good news: there is an entire community that uses, checks and fixes these components when necessary. It is up to you though, to learn of security vulnerability alerts and new versions, and update your software when necessary.
WhiteSource Research: In commercial projects analyzed, over 95% of vulnerable open source components had a newer version available
Doing things differently - automate your open source management:
1. Know what open source components you are using in your code, including dependencies, and their licenses
2. Set an open source policy and enforce it
3. Be alerted when the policy is not adhered to
4. Get alerts when security vulnerabilities are discovered and when new versions are available
read more about the most prominent open source risks in 2018
AND DO IT ALL EFFORTLESSLY!