The sagas are well-known – the software vendor that was forced to take a profitable software product off the market. Or the undiscovered software vulnerability (remember Heartbleed?) that put millions of software users at risk.
The culprit? An open source component that is built into a commercial software product which then violated the open source license. Or that contained a software vulnerability that no one knew about. Open source security and compliance risk is reaching epidemic proportions – threatening the very integrity of the software supply chain.
And the buck stops at the chief executive officer’s (CEO’s) office.
As much as 50 percent of the code found in most commercial software packages is open source. Most software engineers use open source components to expedite their work – but they do not track what they use, understand their legal obligations for using that code, or the software vulnerability risk it may contain.
Worse yet, most software executives have no idea that this is going on. And if they do not know what open source software (OSS) is used, they can’t ensure the proper processes and automation are in place to minimise open source security and compliance risk. Software CEOs need to confer with their chief technology officers, security officers and engineers to understand the state of their open source compliance and security operation. There are a number of key areas that CEOs must query when exploring their organisation’s software supply chain and open source compliance and security operation.
A decade of change
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 senor 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.
Education, time management and an open source review board
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.
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.
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.
Finally, the CEO should look from the outside and see how easy it is to check for signs of proper open source license and security compliance. 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 are all great tests that can be used to gauge your maturity around proper open source usage. By setting a good example, and expecting compliance by their suppliers, the modern company can be assured they are acting like a good open source citizen and protecting themselves and their customers from the side effects of being behind the curve.