Reduce open source software risks in your supply chain

Knowing what’s in your open source software, whether you’re a consumer or producer, can help you manage security risks in your supply chain

Modern open source software (OSS) is a movement that started in the eighties as a reaction to commercial software becoming more closed and protected. It allowed academics, researchers, and hobbyists to access source code that they could reuse, modify, and distribute openly. While the adoption of OSS in the corporate world was initially slow, it grew tremendously over the last two decades, and today almost all corporate software projects include some open source software. 

The rise of open source software

The 2021 “Open Source Security and Risk Analysis” (OSSRA) report, produced by Synopsys, has aggregated open source software usage in audited codebases for many years. The latest iteration of the annual report found a 259% increase of open source libraries in commercial codebases over the last five years, and 98% of codebases audited in 2020 depended on at least one OSS library. 

Download the 2021 OSSRA report

There are very good reasons for that growth. Open source software can provide all the common building blocks of modern software, so the project team can concentrate on what makes its application unique. In most cases, those building blocks are free, of good quality, and have an active community making sure it stays up-to-date. This, however, can stay true only because many OSS users are also OSS contributors. In other words, open source is about sharing source code and enhancing it as a community. 

This source code sharing principle is enforced through one or more licenses applied to each library. There are many different licenses, and their terms can range from the very permissive to the extremely restrictive. In some cases, a corporate project needs only to disclose which libraries it uses and who holds their copyrights. With other licenses, a corporate project is required to distribute its own source code under the same license, and this can be true even when the project code is used only to deliver a service. That, of course, can conflict with the way a company wants to protect its ability to exploit the commercial value of its software. 

This means that open source software library licenses have to be managed properly in corporate projects, taking into account the specificities of the project domain, its distribution mode, and the way OSS is used by the project application. This starts by having an accurate Bill of Materials (BOM), which is the inventory of OSS libraries used in the project, in order to identify the libraries used and the open source licenses applicable. Some companies maintain a BOM by requiring their developers to declare the open source used. While this is better than not doing anything, libraries often are included without declaration due to lack of awareness or laziness, the sheer volume of open source being used (and its associated dependencies), and even potential malicious intent. A much better approach is to use a software composition analysis tool, especially one with multiple factor mechanisms, such as Black Duck®. 

However, that’s just one part of the solution. It can be efficient, but only if used in conjunction with a well-defined and enforced compliance process that includes education, detection, and validation. As each company is different, this process must be tailored to legal requirements of the business, the type of software produced, and the internal organization. 

Traceability of open source software is difficult in software supply chain

The problem becomes more complex when a company relies on one or more software providers and integrates the provided software either directly as a software dependency or through the firmware of devices embedded in their products. While supply chain traceability requirements have been common in the market of physical goods for a long time, traceability of OSS in the software supply chain is relatively new and has only recently started becoming a key aspect of the software industry. 

Too many companies are simply not ready for that. The 2021 OSSRA report found that 65% of audited codebases had license conflicts, and 26% had unlicensed third-party code. Those numbers are slightly lower than what was found in the 2020 report, which could indicate that companies are starting to address the issue, but that’s still worryingly high. 

The issue is compounded in the context of the supply chain. If a provider can’t identify the OSS license risks lurking in its own code, how could its consumer? Depending on the way the software is delivered, the consumer could systematically scan it before accepting it. This is possible if the deliverable is source code, and it’s possible if the deliverable is binary code—it can be done by using a binary scanner such as the one provided with Black Duck—but it can become very complicated if the deliverable is hardware with embedded firmware in it. It’s good practice to scan what you receive, but when issues are detected at that stage, they will trigger a time-consuming process of getting the provider to update its software before shipping again. 

This is a problem that other markets address by proper supply chain management practices. The irony is that even as software has done so much to improve and modernize the supply chain management of global goods markets, it’s now clear how outdated the industry’s own supply chain management can be. 

Reducing risks in your supply chain

For a start, enforcing a good open source software license compliance process for your own software development is crucial. That effort spans across various teams inside your company. Legal experts will need to build a precise assessment of which licenses are acceptable, in which context, and a set of rules to determine how a previously unassessed license should be treated. Software engineering teams need to be educated about the legal implications of open source software usage, and know what to do when considering new OSS libraries. Your software factory should also take OSS licenses into consideration when doing integration and delivery, potentially rejecting high-risk builds. As previously stated, a good software composition analysis tool is also key to getting a quick and accurate view of what OSS is present in your software, so you can assess the risk it represents based on rules defined by your legal experts. 

Of course, those efforts need to be applied to all the software you deliver, which also includes software written by your producers. In other words, it’s good practice to ensure that your producers apply the same level of open source software compliance effort as you do. You need to be able to trust that your producers have educated their staff as you’ve educated yours, and have put in place OSS license compliance workflows. Their process doesn’t have to be the same as yours, but they have to produce the same level of confidence. After all, if your provider introduces a contaminating license in a deliverable, it may end up in yours, and both of you will be exposed to the risk. 

You also have to be clear about the licensing rules you need to enforce; your provider can’t guess which licenses are acceptable. When dealing with a provider in the context of a project, acceptable licenses must be part of your requirements, just as much as features, performance, and security are. That doesn’t completely eliminate the risk of a contaminating license slipping through the net, though. An OSS sanity scan should still be part of the acceptance phase, as it gives you clear entitlement to reject a delivery if not compliant, which in turn reduces the risk of noncompliance. 

Collaboration is key

Even if you have reached some level of maturity in your internal open source software compliance management, knowing how much to trust your producers can be difficult because you probably can’t afford to investigate their internal procedures to decide whether they are up to your standards. Fortunately, the OpenChain project was created to address exactly this issue and has now become the ISO 5230 standard. The vision of OpenChain, a Linux Foundation project, is to create a supply chain in which open source is delivered with trusted and consistent compliance information. To accomplish that, the project established clear requirements to ensure effective management of open source for software supply chain participants. Being certified by the project means that you meet those requirements and are ready to collaborate with the other certified supply chain stakeholders, such as your providers or customers. 

Even if you’re at the very beginning of your open source software journey, the OpenChain project can be a very valuable source of information about how to progress in this journey. It provides a wealth of freely available materials describing the requirements and ways to meet them, so you can gradually put them in place on your way to getting certified. 

Secure the weakest link in your supply chain

Companies are at various levels of maturity regarding their open source software compliance, ranging from nothing to well-defined programs. But when it comes to the supply chain, the risk is really defined by the least mature part of the chain. Some companies are already acting to ensure that their weakest link gets stronger, for example, through participation to the OpenChain program, but we are just at the beginning of this movement. We can expect in the coming years to see OSS compliance as an increasing part of supply chain requirements, including in industries well outside of software or traditional technology concerns. That’s a good thing, because even if it can represent extra effort from providers, in the long run it will greatly reduce the risk and associated costs. It does mean, however, that companies that fail to address this today might tomorrow find themselves struggling to find a place in the software supply chain.