By Jeff Luszcz, Vice President of Product Management at Flexera Software
The consequences are easily recognizable; you remember the lucrative software product whose vendor was compelled to shelf it. You probably also remember the insidious software vulnerability that harmed millions of unsuspecting users (Heartbleed, anyone?).
But what caused these issues? Itis what happens when an open source component is integrated into a commercial software product and violates its open source license, or when it contains a vulnerability that was previously unknown. As technology evolves, open source security and compliance risk are reaching a critical apex that if not addressed, will threaten the entire software supply chain.
So who is responsible if you are not prepared, and your company is affected? The CEO.
Up to 50 percent of code in commercial software can be defined as open source, while the majority of software engineers use open source to accelerate their work. The problem with this is that most engineers do not track what they are using. They also tend not to grasp the legal ramifications for using that code, nor the potential software vulnerability risk they are inviting once adopting it.
The most startling aspect of it all is that most software executives are not aware of this risk either. If you do not know what open source software is being used, you can’t guarantee that the appropriate methods and automation are established to reduce OSS and compliance risk. That said, it is imperative for software CEOs to deliberate with CTOs, security officers and engineers to gain a vast comprehension of the key areas of their open source compliance and security operation.
An Open Source Explosion
The way we build software products has greatly changed in the last 10 years. It used to be the case that even the CEO would be highly aware of the third-party dependences their company had on the outside world. The dependencies were often commercial in nature and required non-disclosure agreements (NDAs), contracts, payments and other highly visible activities related to acquiring and licensing the technology. Then slowly at first, and with an ever-increasing pace seemingly overnight, the open source world exploded with millions of extremely high quality, easy-to-acquire, free-of-licensing fee components. The open source business model, combined with a fast always-on-network and the social effects of open source use, created a perfect environment for hundreds – and even thousands – of OSS components to be brought in and added to a software product.
In some cases, there is more open source than homegrown, proprietary code in a company’s product. Unfortunately, most companies, while taking advantage of open source in order to create products faster, are not respecting the open source licenses associated with the software components they use. What is sometimes surprising to CEOs and other executives is that while open source is free of cost, it is not free of obligations. These obligations run the gamut from passing along a copyright statement or a copy of license text, to providing the entire source code for the company’s product. Data shows that most companies are aware of only a small percentage of the open source they depend on. By not knowing what you are using, it is impossible to comply with the obligations specified in the license. Additionally, software can have bugs or vulnerabilities which may affect your product. By not keeping track of what you are using, it can make it possible to be far behind on upgrades or patches that fix discovered software vulnerabilities.
As with most business processes, if they are not seen as important or required by senior leadership they will not get done. Open source license compliance is not an optional part of using open source, but it has been treated that way by most of the tech industry. It is important for CEOs and other business leaders to show the importance of respecting the legal and security obligations that are part and parcel of using open source.
Basic Training
The technical debt that exists around open source compliance requires a multi-prong process, in order to create a climate and a set of expectations that the processes are being followed. The most important of these is education. Everyone in the company should be aware of the basics of open source licensing and compliance. This is because open source is being used in pretty much every business process and job at a modern tech company. Graphic designers are using open source art work, IT is installing and maintaining open source applications, marketing is editing and creating content based on existing open source content, as well as countless other examples. By being trained on the basics, and knowing that compliance is expected, you can make the remaining job much easier. Employees will be more mindful in their choices, be able to respect the open source content they use – and in many cases – be able to give back to the community in an acceptable manner.
Senior Leadership Mandates
After education, comes time management and the process of building open source compliance and vulnerability management into the technical and business processes that a company creates and follows. If no time or resources are provided to comply with the open source obligations, it is not a surprise to see those obligations ignored. While potential legal, security and reputational risk concerns should be enough to bake this into your processes, it is often only after senior leadership mandates that time be created that compliance occurs.
Open a Review Board
It is also recommended that an internal team of open source experts be assembled as part of an Open Source Review Board. This team should be made up of technical, legal and business representatives who can help create policies and act as a clearing house for open source and third-party usage questions.
Questions that Need Answering
CEOs should make it a priority to see how easy it is to check for signs of proper open source license and security compliance from the outside. Is it easy to find the third-party license notices for your products? Is it easy to get any source code distributions required due to our use of Copyleft style open source licenses? Do you have a process and plan for upgrading and patching your products due to open source and third-party software vulnerabilities? Have you asked for spot checks of your compliance documents to confirm that the processes are being respected? Are you providing material support to the open source projects you are using? Have you required your commercial vendors to provide open source disclosures and compliance documents?
These important questions are a useful way to gauge how responsible your company is about proper open source practices. By asking these questions and demanding suppliers comply with these policies, companies can best protect themselves and their customers from the disadvantages of being a laggard when it comes to technology.
