The business rationale for an open source software internal audit

Why an internal audit to mitigate legal and security risks is vital to truly benefit from using open source software in business applications.

This is a contributed article by Jeff Luszcz, Vice President of Product Management at Flexera


There’s no debate about the value of using open source software (OSS) when building new business applications – cost, flexibility, quality and ease of use, to name a few – but its use comes with legal obligations and security vulnerabilities that can pose significant risks to organizations. To effectively pre-empt such risks, proactive OSS management is essential. To this end, conducting an audit of the use of OSS code can help companies get a handle on the emerging risk areas.

The typical, modern software application is comprised of more than 50 percent open source code, while at the same time, surveys show that the vast majority of teams disclose no open source use. This disconnect between the industry’s major dependency on OSS and the lack of knowledge of the OSS in use leads to two types of risks. The first is a security risk due to potential vulnerabilities that have been introduced through the use of a third-party component. The second is the legal risk of not following the compliance obligations present in the same software.


Defining the risks associated with unmanaged OSS use

All software has bugs, and many bugs lead to security vulnerabilities. Open source is not riskier than home-grown software, but since there are often hundreds of third-party components in use with minimal tracking, it’s a common source of vulnerabilities in a codebase. Since the vast majority of software in a product is open source, it’s important to be aware of what’s in use, where it came from, what version is being used and what known vulnerabilities are present. Additionally, outside attackers can take advantage of the fact that there are frequently the same commonly used open source packages present, which allows them to automate or front load their attacks.

Considering the reporting obligations of using open source 

One of the most common legal obligations associated with the use of an open source software component is the requirement to properly disclose and provide the notices or license text as required by the component’s open source license. Many open source licenses require one or more of the following to be passed along to a user: the copyright statement from the original author, the license text of the open source license or a special phrase naming the open source component in use. These obligations are typically required when a product or project is distributed. If a company isn’t aware of an OSS component, there’s no way for that company to fulfil its legal obligations.

Walking through the steps to conducting an audit of OSS use

In order to understand what OSS is in use to reduce vulnerability and compliance exposure, a software audit must be performed. The process of starting an audit to discover open source packages can be straightforward. Software exists to help in the scanning and identification process, and teams can often get a head start working internally to produce their initial Software Bill of Materials (SBOM). As this BOM is created, components will be found that either are vulnerable or contain licenses contrary to the legal policy for the product team or company. The process of fixing these problems is known as remediation. Some remediation steps are as simple as upgrading to the latest version of the software component in question. Others require a more coordinated response. Since the process of upgrading a component may require lengthy validation and integration tests it’s also common to see initial non-source code change actions such as putting into place firewall rules, turning off features or shutting down the entire system.

Other remediations may include the complete rewrite of a feature if the open source component is no longer maintained or has a license that can’t be used. 

A team should understand why their audit is being performed. For example, is it primarily concerned with vulnerability detection or open source license compliance? The architecture should be examined in order to discover all the modules required to build and run the product. Third-party dependences should be detailed, and any software repository management systems like Maven or NPM should be discovered. These systems are often the source of a high percentage of the open source in use, but due to how these systems work, they often hide the complexities of the OSS components in use.

Depending on the type of product that’s being built, how it’s distributed and who the customer is, the team may be required to perform a more comprehensive review. This review may include examining the software supply chain to discover and manage the open source brought in through commercial components or infrastructure pieces, or performing a deep dive of source code cut and pastes or binary files.

Once a software audit has been started, it’s important to keep the BOM up to date. By keeping the bill of materials current, it becomes possible to rapidly respond to new vulnerabilities as they’re discovered, as well as update components and versions in use as the team makes changes. Providing third-party notices or disclosures is becoming an important part of the software sales process, even in cases where a component may not have an explicit notice requirement. As we look to the future, companies who manage their open source well will have a security and legal advantage over those who don’t, and will also be able to best understand which open technologies they should support.