Posted by Steven Zimmerman on July 7, 2017
If you’re part of a modern business that does any software development, your dev teams are using open source components to move quickly, save money, and leverage community innovation. If you’re a law firm or a consultant, your clients use open source. And if you’re on the lookout for your next acquisition, you’ll be evaluating targets replete with open source. Synopsys recently found that proprietary applications we audit are 36% open source on average.
Since I’ve been working at Synopsys, I’ve learned a great deal about open source — and how and why an audit of the code base is important. I’ve also heard stories from customers scrambling to create a plan that addresses concerns about open source software risk during mergers and acquisitions (M&A) — before it jeopardizes the deal. This scramble makes me wonder how well the companies involved understand how their solutions are built.
It’s important to consider why you’re doing an audit — why you need to examine your dev teams’ projects, open source components, and license requirements.
For many, impending M&A activity drives an audit. After all, when buying, you want to acquire high-quality assets free of legal or security issues and, when selling, you want to be a high-quality asset. Buyers want to have a good handle on the risks they are taking on so they can value and structure the deal appropriately. Those buyers want to know that their target does not bring with it unaccounted for baggage. They’d like to know the company is using open source components within the bounds of their licenses, is resistant to cyberattacks, can ensure consistent uptime, and that their data — and their customers’ — will be secure.
Some organizations opt for an internal open source audit because the leadership team has been reading news covering open source vulnerabilities, exploits and possible breaches. Some teams may be concerned about the intellectual property risks due to non-compliance with open source licenses. What’s driving your organization’s choice? Your reason makes a difference in who you involve and your goals.
When preparing for a code audit, understand that developers are focused on producing quality code quickly. While developers may understand the implications of open source licenses, they may not be concerned about the fine print of the thousands of open source licenses in the wild today. They may also not have the time or resources to track new security vulnerabilities announced every day.
Senior leadership, legal departments, and senior technical managers are usually the ones charged with the strategy, policies and processes associated with open source management. This allows developers to focus on developing software while providing them with guidelines to avoid risks. When performing code analysis, all of these groups can contribute to analyzing results and addressing issues that arise.
Good open source audit service providers should take the time to review the results of an application audit and provide actionable insight into:
This is when your experts will take over the results, leveraging the auditors’ insight to clarify any questions. This is a critical step, because what the audit uncovers may have a material impact on the valuation of a business and the deal terms during an M&A.
Maybe something needs to change, maybe it doesn’t; the results of your audit will help you answer that question. If your audit showed exactly what you expected, you’re in the minority. When we did an analysis of our security audits from 2016, we found that 96% of applications scanned used open source, and companies were only aware of about half of the open source in use. The great majority of code bases we analyze have license and security issues.
The output of an open source audit provides clear information about not only the open source code in use, but the known vulnerabilities in the code, not to mention the license compliance risks. This information not only gives you a clear picture of what’s in your code, it can help you be better prepared moving forward. Creating open source management policies based on how you’re actually using your code is one way you can use your audit results.
As I mentioned, the most common reason for an open source audit among our customers is for merger and acquisition events. A snapshot of the open source use and risk exposure of the code in question provides much needed information to help you move forward as a buyer or a seller. Buyers get visibility into risks they may be taking on; sellers have the opportunity to address such risks in advance of due diligence. If you anticipate being on either side of a transaction, the Black Duck by Synopsys Audit team can help you decide how to proceed.
Get the latest Software Integrity news, thought leadership, and more.