Open source software management practices have played catch up to usage for years. In most organizations, open source use started as a grassroots movement. That’s why it has taken time for management to understand the issues and put processes in place. But there’s still much work to be done. Gartner says that while virtually every organization relies on open source, many still lack any sort of usage policy let alone controls.
M&A Industry Leads the Charge
Well aware of the importance of open source license compliance are organizations that acquire technology companies. While it was once rare for the subject of open source license compliance to even come up during technical due diligence, today it is on the check list of most North American acquirers. At a minimum, they are asking questions about open source usage. Many acquirers also employ open source audits to assess the composition of their target company’s code base. Big drivers of these efforts are IP attorneys who have educated their clients on the importance of understanding a target’s code assets from a licensing perspective
That awareness continues to be fueled by an ongoing series of lawsuits, primarily over copyright issues involving particular open source licenses known as reciprocal (also copyleft or viral) licenses. Improper use of these licenses can impinge upon a company’s proprietary intellectual property. Understanding the composition of software code and identifying potential issues enables acquirers to assess and address IP risk before the deal is finalized.
While still evolving, the North American M&A community has achieved a reasonable level of maturity with respect to open source license risk. (Elsewhere in the world, however, awareness and best practices are a few years behind.)
Security & Operational Risks: The New Blind Spot
But what many M&A professionals don’t realize is there are other serious risks beyond open source license compliance. They include a growing number of security and operational risks.
The broadly publicized Heartbleed bug in 2014 went a long way to sensitizing the tech community to the specter of security vulnerabilities in open source components. Surprisingly, thousands of other vulnerabilities had been identified even before that time. But none had received the notoriety of Heartbleed, which brought to light the potentially serious security issues posed by open source software. As recently as two weeks ago, a serious vulnerability surfaced in glibc, a popular component we have found in about 7% of the code bases we’ve audited in the last couple years.
As well as risks posed by security vulnerabilities are operational risks related to component maintenance. If there is an active community contributing to an open source project, problems will be fixed by the community, often before you are even aware of them. However, if a component lacks an active community, there’s a great risk that the user will be left hanging. And, unless you have a process for updating to new versions, bugs of all sorts – including security vulnerabilities – can linger in open source, since few communities push out updates, relying on their users to pull down updated versions. For example, even almost two years later, older versions of OpenSSL are still broadly in production.
The takeaway I hope you’ll think about: During due diligence, once you have a software bill of materials, don’t stop at just examining open source license compliance. It’s also important to assess the growing number of risks posed by security and operational threats to avoid the full range post-close surprises.