Understanding the hows and whys of open source audits

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. In the most recent Synopsys “Open Source Security and Risk Analysis” report, we found that 78% of all code analyzed was entirely open source.

While the prevalence of open source components is now widely understood, the implications of software license conflicts, unknown dependencies, and vulnerable components are often underestimated or overlooked. Unresolved issues consequent to open source in digital assets can negatively influence mergers and acquisitions (M&A). It's the responsibility of those involved in these engagements to adequately scope this influence and mitigate the issues that can spoil a deal.

Why bother with an open source audit?

The first step toward an effective and actionable audit is to consider why you’re doing an audit. Are you doing it for internal purposes, or are you doing it to prove your resources are assets rather than liabilities?

For many, impending M&A activity drives an audit. After all, when buying, you want to acquire high-quality assets free of legal, security, and quality issues. 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 baggage that is unaccounted for. They’d like to know the company is using open source components within the bounds of their licenses, that it is minimizing potential cyber attack vectors, that it can ensure consistent uptime, and that its data—and its customers’ data—will be secure.

Some organizations opt for an internal open source audit because the leadership team has been reading news about open source vulnerabilities, exploits, and possible breaches. Some teams may be concerned about the intellectual property risks due to noncompliance with open source licenses. What’s driving your organization’s choice? Your reason makes a difference in who you involve and your goals.

Who do you involve in your audit?

As the focus on digital transformation heightens, development and release velocity expectations rise, which is a heavy burden placed on developers. As a result, they depend more and more on open source for foundational functionality so they can spend more time on innovation.

When preparing for a code audit, understand that developers are focused on producing the highest-quality code possible given tight deadlines. It’s important to not assume that developers understand the complex license terms often associated with the open source components they leverage. The same often goes for security vulnerabilities. Regardless, the scale of open source usage has far outpaced the ability to manually track these types of risks.

Senior leadership, legal departments, and senior technical managers are usually the ones charged with identifying the strategy, policies, and processes associated with open source risk management. Unfortunately, this does not always prescribe clear mechanisms to manage developers' consumption of open source libraries. Developers often place more weight on a solution that meets the task if the alternative can mean missing a shipping deadline.

What do you do with the audit results?

Software audits come in many different shapes and sizes. There are, however, several areas of consideration that should be addressed to make the audit insightful and actionable.

• Copyleft licenses and other license obligations
• Unlicensed code
• Open source security vulnerabilities
• Operational risks and technical debt associated with open source

An audit report should focus on these areas. And the parties should review these topics with the auditor, who’s experience can provide clarity and answer specific 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. For example, different licenses pose different levels of risk
depending on the industry in which a business operates, the sensitivity of data it touches, the external/internal orientation of the software, and more. The same goes for security vulnerabilities; they may affect web-based applications differently than they do embedded applications. These are the types of considerations that an expert audit group can advise on.

How do you use your knowledge?

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 2021, we found that 97% of applications scanned used open source, and companies were only aware of about half of the open source in use. The majority of codebases 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 also the known vulnerabilities in the code and the license compliance risks. This information gives you a clear picture of what’s in the target’s code, and it can help you be better prepared moving forward.

If your goal is to assess your own code for internal purposes, audit results arm you with the information to create open source risk management policies for future development efforts. If your audit is for an M&A or due diligence situation, the results provide invaluable information necessary for determining deal value and risk.