With a software bill of materials (software BOM), you can respond quickly to the security, license, and operational risks that come with open source use.

A software bill of materials is a list of all the open source and third-party components present in a codebase. A software BOM also lists the licenses that govern those components, the versions of the components used in the codebase, and their patch status.

Who needs a software bill of materials?

Any organization that builds software needs to maintain a software BOM for their codebases. Organizations typically use a mix of custom-built code, commercial off-the-shelf code, and open source components to create software. As one principal architect of a leading software supply chain provider notes, “We have over a hundred products, with each of those products having hundreds to thousands of different third-party and open source components.” A software bill of materials allows organizations to track all the components in their codebases.

The concept of a software bill of materials derives from manufacturing, where a bill of materials is an inventory detailing all the items included in a product. In the automotive industry, for example, manufacturers maintain a detailed bill of materials for each vehicle. This BOM lists both parts built by the original equipment manufacturer itself and parts from third-party suppliers. When a defective part is discovered, the auto manufacturer knows precisely which vehicles are affected and can notify vehicle owners of the need for repair or replacement.

Similarly, smart organizations that build software maintain an accurate, up-to-date software BOM that includes an inventory of third-party and open source components to ensure their code is high quality, compliant, and secure.

What’s in a software bill of materials?

Open source components
Have your developers used open source components in your code? There’s better than a 90% chance that they have. Open source helps you shorten development time, increase speed of execution, and profitably deliver your products to your customers. Analysts such as Forrester and Gartner note that the vast majority of IT organizations use open source software for mission-critical workloads and that some applications comprise up to 90% open source components.

But few companies have much visibility into the open source they use. Even fewer can produce an accurate, up-to-date software bill of materials that includes open source components. A comprehensive software BOM lists all open source components in your applications as well as those components’ licenses, versions, and patch status.

Open source licenses
Do you know whether the licenses for the open source components your applications include are permissive or viral? Are you using one of the top open source licenses or a one-off variant?

Failure to comply with open source licenses can put businesses at significant risk of litigation and compromise of intellectual property (IP). In 95% of the scans our software audit services team conducts, we find open source that the target doesn’t know was there. Furthermore, 68% of the codebases we audited in 2018 contained components with license conflicts. A software bill of materials lists the open source licenses that govern the components you use, allowing you to assess your legal and IP risk.

Open source versions
Do you know whether the open source components in your codebase are being maintained? Operational risk is an important consequence of open source use. Many open source components are abandoned. In other words, they no longer have a community of developers contributing to, patching, or improving them. In fact, a recent Gartner survey found that the “long-term viability of open source projects” was a top concern of development organizations.

When a component is inactive and no one is maintaining it, no one is addressing potential issues such as weaknesses and vulnerabilities. Our audit services team found that 85% of the codebases we scanned in 2018 contained open source components that were more than four years out-of-date or had no development activity in the last two years. A software bill of materials lists the versions of the open source components in your codebase, so you can determine whether you’re using any outdated, potentially insecure code.

Open source vulnerabilities
Do you know whether the open source components you’re using have any known vulnerabilities? While the number of vulnerabilities in open source is small compared to proprietary software, over 7,000 open source vulnerabilities were discovered in 2018 alone. Over 50,000 have emerged over the past two decades. Our audit services team found that 60% of the codebases scanned in 2018 contained at least one open source vulnerability, and over 40% contained high-risk vulnerabilities.

Only a handful of open source vulnerabilities—such as those infamously affecting Apache Struts or OpenSSL—are ever likely to be widely exploited. But when such an exploit occurs, the need for open source security becomes front-page news, as it did with the Equifax data security breach of 2017. A major contributing factor to Equifax’s breach was the company’s lack of a comprehensive IT asset inventory—in other words, a software bill of materials. “This made it difficult, if not impossible, for Equifax to know if vulnerabilities existed on its networks,” a report on the incident concluded. “If a vulnerability cannot be found, it cannot be patched.”