When’s the Right Time for an Open Source Audit?
Table of Contents
How much do you really know about your open source usage? Can you identify what open source components you’re using? How about which licenses are in play and whether you’re compliant? Do you have a good sense of how many open source security vulnerabilities are in your code base and how to remediate them?
Chances are, if you’re like most organizations, you can’t answer all of these questions. Considering that open source components now make up 80% or more of modern applications’ code base, not knowing seems like a grave omission or, worse yet, an unnecessary and avoidable risk.
So how do you gain visibility and control over your open source usage? The answer is with an open source audit.
What Is an Open Source Audit?
An open source audit is a thorough investigation into your open source components done by a certified auditor. It has three key elements: an inventory of your open source software, an analysis of your licence compliance, and an assessment of open source security vulnerabilities. Together, these give you a risk analysis of your open source use with actionable insights.
The first step in an open source audit is to identify all your open source libraries, including any direct or transitive dependencies.
Once you’ve identified your open source inventory, you need to make sure your open source licenses are compatible with each other and adhere to your company’s policies. It’s not as simple as a library operating under a single license like the Microsoft Public License. In many open source libraries, dependencies have different licenses. Some of these licenses might be more permissive such as Apache and BSD, and some may be a more restrictive copyleft license, like GPL. It is important to understand how your licenses relate to one another to ensure their compatibility.
An open source audit also digs deep into security vulnerabilities. A thorough scan of all your open source components identifies any potential security threats or out of date components and CVE vulnerabilities. A fix or upgrade path should be specified as part of this process.
When Do You Need an Open Source Audit?
Though it’s always a good idea to have visibility into your open source use, there are several instances where an open source audit is required. These include the following:
- Distributing software. Any time you distribute software that contains open source libraries, an audit ensures you’ve met all licensing requirements. The last thing you want is to face legal action because you failed to disclose several copyright notices.
- Quarterly reports. Public companies must disclose their open source components in their quarterly filings.
- Mergers and acquisitions (M&As) and initial public offerings (IPOs). Potential buyers or investors need a record of all open source components in their target’s code base, together with their licenses, to identify any instances of copyright infringement. Open source audits shorten the length of an M&A’s due diligence, and studies have shown that the longer the due diligence process lasts, the higher the chances are that the deal doesn’t get signed or the value is significantly reduced.
- OEM agreements. Similar to distributing software, you must also disclose open source use when selling your software to another vendor for inclusion in their own product, such as under an OEM agreement.
Open source due diligence is a critical part of overall software due diligence. Being proactive by engaging in an open source audit can limit your company’s exposure and often gets the deal done.
Why Isn’t Everyone Doing an Open Source Audit?
{BANNER}
We’ve shown you some of the reasons open source audits are critical, so why isn’t everyone doing one?
In many organizations, open source audits are extremely time consuming because they do not have the required visibility into their open source usage. Given the high volume of open source components and their dependencies, tracking open source components manually is next to impossible and the results of such audits are likely to be highly inaccurate.
The solution? Using an automated software composition analysis (SCA) tool and bringing in a professional to help you perform an open source audit. An automated SCA tool combined with a professional’s expertise gives you visibility, and visibility is the first step toward rectifying any open source compliance or security issues lurking in your code.
What’s Included in an Open Source Audit?
A comprehensive Open Source Audit report begins with an executive summary that highlights your organization’s risk areas. It also includes the following detailed reports that contain actionable insights:
- Due Diligence Report. This report lists all open source libraries detected during the audit. It may also include additional information such as open source licenses, risk score, and copyright information.
- Security Vulnerabilities Report. This report lists all the known security vulnerabilities discovered during the audit. Detailed information about the type of vulnerabilities, their location in your projects, and suggested fixes are included.
- Attribution Report. The attribution report lists all the licenses for each project and includes license text and copyright information whenever it is available.
- Compatibility Risk Report. This report includes a list of out-of-date or multi-versioned libraries. It also includes recommendations for updating these open source libraries.
- Audit Report Walkthrough. This is usually a hands-on session in which the auditor walks the client through the audit’s significant findings. It highlights the client’s greatest open source risk areas and gives recommendations for remediation. Though not included in every open source audit, Mend provides this valuable walkthrough as part of our standard audit.
After the Audit
Once an open source audit has been completed, there usually is work to be done to remediate security vulnerabilities and ensure licensing compliance with all your open source components. Though the list may be daunting, it is better than not knowing.
Let’s be honest: Companies don’t do open source audits for the fun of it. They do it because it’s required by law or as part of due diligence to help close a deal. Understanding your open source risk by undertaking an open source audit is the first step in achieving compliance and greater security, not to mention peace of mind.
So when is the right time for an open source audit? Now. The time is definitely right now.
