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