Using open source software (OSS) allows organizations to add tested, proven functionality to their code base, without having to write the code from scratch or purchase third party, proprietary code to add the same functionality.
Estimates now indicate over 90 percent of all companies use open source in their commercial software, and that up to 80 percent of all code in new Java applications is from open source components.
If one looks at public repositories, including the Central Repository and SourceForge, over 13 billion downloads occur every year.
This benefit comes with risk, however.
The vast majority of companies using open source have little, if any, oversight as to the selection and use of the libraries and their licenses. In addition, millions of OSS components with known vulnerabilities are downloaded for use each year. There is good news, though: managing this process better is possible.
In order to manage this process, you need to know the root of the problem lies in the lack of controls over the selection, use, and monitoring of components. You can manage these open source challenges by establishing OSS policies and maintaining them once they are in place.
Establish OSS policies
The first step is to document internal policies for open source use. This includes the types of licenses you will allow, any security requirements you may have, and determining how the OSS package will be supported.
These decisions are determined by each organization primarily by their appetite for risk, compared to the value derived from the open source, for each class of applications. Internet-facing applications and those apps that access sensitive information require a higher security standard than some internal applications (with a smaller perceived attack surface).
Good open source practices are good development practices, but we also need to recognize development realities. Open source often enters a code base organically; a developer thinks about functionality and deadlines. If she requires specific functionality, has used the open source previously, she is inclined to use it again to accelerate productivity.
Finally, we need to institutionalize the policies. While many organizations have some standards, our research shows that those typically are not well managed or enforced. A successful governance program requires a certain level of discipline, and occasional trade-offs. Exceptions to the policies may ultimately be necessary due to design choices, functionality, or market pressure, but these should be taken with full awareness by all parties. Most importantly, a successful governance program requires the ability to detect breaches of policy after the review is completed.
Feed and maintain policies
As you develop your best practices for legal, technical business, set up a pipeline via your OSS review board to constantly update your policies.
OSS policies are based on multiple factors. Legal, technical, and business are the top three. You’ll need to ask yourself:
• From a legal view, what risk and practices do you want your team to utilize to ensure compliance and risk avoidance?
• From a technical/security view as you monitor and update OSS, what version and packages do you want to avoid or which version do you want your team to use?
• From a business view, when is commercial software better? What business issues need to be addressed by OSS? Should you only use supported OSS?
By having the right policies in place, an organization can avoid the headaches that often come with OSS. By bringing legal, security, and support risks into consideration early and often, your organization should be able to safely reap the many benefits that the open source community has to offer.
Managing open source risk
Open source use is certainly beneficial, and the risks can be mitigated. That is, if we are using more and more open source, without putting controls in place, we are inviting unmanaged risk into our applications.
Through our recent research we found that:
• 76 percent of the organizations we interviewed admit they have no meaningful controls.
• 80 percent of the developers state that they can use any open source package they choose, without proving the security of those components.
• Only 20 percent claim to track vulnerabilities in OSS over time.
These are scary findings; something that shouldn’t be ignored. We’ve learned that it’s vital to think about license, security, and support concerns when creating applications. Being mindful of your entire codebase, and creating and following a thoughtful policy, will leave you with applications that are more secure, more reliable, and – in time – more in-demand with consumers.
• To learn more about our recent research, download this white paper.
• Want to start building your own open source policy? We can help.