Revenera logo
Image: When is the right time to conduct an open source audit?

No matter what industry you are in, your company’s code most definitely contains code from someone else.  Today’s software is not written from scratch, but rather assembled from parts.  These parts mostly originate from open source software that’s freely available from the internet.  However, your awareness should not be limited exclusively to open source.  Third-party code may also originate from commercial software or from an unknown origin with unknown license terms.  Unless companies have policies in place specifically to track the third-party code and educate their employees to follow these policies, it is almost impossible for any code owner to produce an accurate bill of materials without first conducting a code review.  As a software auditor, one of the most common questions I get is, “When is the right time to conduct an open source audit?”  Below are a few common scenarios where open source audits are necessary.

If you are the Target company in a Merger & Acquisition (M&A) or an initial Public Offering (IPO), you will almost certainly be required to go through open source code review.  During this process, you will be expected to provide a comprehensive Software Bill of Materials (SBOM).  An SBOM is an inventory of all third-party components found in a code base.  Producing the SBOM is one of the most important exercises a code owner will go through.  Without the right technology, it can also be a time-consuming process.  Anyone who has gone through this process knows that the open source code review could take three or more weeks, depending on the size and the complexity of the code base.  If you are preparing for an M&A, we recommend that you start this process early in the M&A process to help shorten the length of your acquisition timeline. Starting earlier also helps avoid possible delays if the audit turns up license compliance or vulnerability issues that need remediation.

As a software provider that distributes code to customers or partners, it is crucial that you have a thorough understanding of what open source is being used to make sure that you comply with all the license requirements.  In certain cases, some viral licenses (like the General Public License aka GPL) require you to provide your source code.  One of the triggers for this requirement is when you distribute your product to a third-party.  You could face legal action if you don’t fulfil these license obligations for the open source code that’s being shipped.  If your organization can produce a complete and accurate SBOM, it minimizes the chances of expensive litigations.  One of the best ways to produce that SBOM is to conduct an open source audit.

It is also important to understand the concept of the software supply chain. “The supplier to my supplier is also MY supplier.”  Any organization that uses open source must understand supply chain risks and must fulfil the license obligations of not only its own proprietary code, but also comply with the license requirements for the code that’s received from its suppliers.  Even if your organization uses tools and has policies and procedures in place around the management of open source software, you have no way of knowing and guaranteeing that your supplier’s code meets all the open source license requirements without a review. Should you  take their word for it?  I wouldn’t.  Unless, however, your supplier provides you with an accurate SBOM.

Additionally, the impact of unpatched vulnerabilities brought in by the use of open source has grown markedly in the last few years. All software has defects, and the number of open source packages in use means that the typical application contains significant risk if these packages aren’t managed and upgraded when new vulnerabilities are discovered. More customers and partners today are requiring SBOMs and timelines for vulnerability patching as part of their contracts.

Open source code is freely available and every company uses it.  In my 15 years of industry experience as an open source auditor and now as a Services Manager, I have yet to see an organization that doesn’t use open source extensively, while at the same time most organizations undercount their use of open source. In 2021, only 4% of the open source issues eventually uncovered during an audit were disclosed prior to audit start.  Just because open source is freely available does not give anyone the permission to use it.  To get the full benefits of using open source you have to properly manage and secure it.  Not having a complete and accurate SBOM and not complying with license requirements or upgrades can expose your organization to litigation and security risks.  There are various triggers that may force your company to go through the audit, some of which are: M&A, IPO or physically distributing your product.  Problems identified by other companies outside of your organization often occur at the most inconvenient times.  This can cause delays and loss of revenue because suddenly companies need to stop production and resolve issues.  This can have a trickle-down effect on personnel and budget because companies may have to make new strategic decisions because of remediation or litigation costs.  If a serious issue is found, it can pause or stop M&A or IPO.  And, in the worst case, surprise issues can cause companies to go out of business or shut down products.  It is better to learn and deal with these potential problems on your own terms.  For these reasons and many others, it is becoming more clear that every organization needs to understand what goes into their products.  Audit services can help you get a jump start on this very important requirement.