SBN

When’s the Right Time for an Open Source Audit?

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. 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. 

  •  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, WhiteSource 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.


*** This is a Security Bloggers Network syndicated blog from Blog – WhiteSource authored by Julie Peterson. Read the original post at: https://resources.whitesourcesoftware.com/blog-whitesource/when-s-the-right-time-for-an-open-source-audit