What is an open source software (OSS) bill of materials (BOM)? In the simplest terms, it is a list of the OSS components used in an application. But, it can actually be much more. Most OSS BOMs will, at a minimum, also contain the licensing information associated with each OSS component.
In this article, we will explore what should be included in an OSS BOM, whether you create it, or you hire someone to scan and audit your code and create a BOM for you. We will also talk about deciphering the information in a BOM, and the possible next steps.
Perhaps the best way to describe an OSS BOM is to delineate how to use it. The BOM should provide the information you need to track the OSS you use by application. Here is a list of information usually included in a BOM that will provide varying levels of value, depending on your plans around managing the open source you use:
1. Component name
2. License (if no specific license terms, provide origination information such as author, copyright holder, website where it was obtained, etc.)
3. Component version
4. Copyright information
5. Usage information (many license obligations are triggered by how the component is used; for example, whether the original component is modified, or if it is combined with other code)
a. Is it modified?
b. Do you link your code with it?
c. Is it distributed to customers, or is it for internal use only?
d. How is it distributed (Media, Device, SaaS, etc.)?
6. Security vulnerability info (any outstanding CVEs in the national vulnerability database, for example)
7. Website address where the component was obtained.
Once you have your BOM, what next? How do you make sense of the information? What value does it provide to you and your organization?
Take the following example: you hire someone to create a BOM for you. You provide your application code, and they use tools to scan your code for matches to OSS. After a period of time, they provide a document to you that contains a list of the OSS components and licensing information. What now?
Here are a few simple steps for reviewing an OSS BOM, and for preparing for the next steps.
1. Review the list of components and determine if they are in line with your expectations.
a. If you already had a rough list of components compiled by the team, review any missing or additional components on the BOM, and ascertain why the discrepancies exist.
b. Confirm that the list is accurate.
i. Many times during an audit, the BOM will show outdated components you thought you had removed, or ones that are no longer used. Remove them from your code, and update the BOM. You do not want to distribute a component that could cause license compliance issues, especially if you do not even use it.
ii. The BOM may list a website where the OSS component is hosted, but you obtained it from a forked version at another location. Origination can be important for a number of reasons; for example, obtaining updates, or checking licensing or copyright information.
2. Review the list of licenses.
a. Review each license. Some are short and easy to understand, like the BSD or MIT licenses. Others may be more complex, like the GNU licenses: GPL and LGPL. If you are new to OSS licenses, you may want to get some legal help. Ask your lawyer to review the terms of the various licenses and give you an assessment of risk, and what steps to take to comply with the licenses.
b. If there is no license, the review may be a bit trickier. What if the BOM includes code taken from a web-based tutorial, or a blog article where the author does not explicitly state the licensing terms? If the free code you grabbed for your app does not have specific licensing, there is still the chance that using it may infringe on the original author’s rights under copyright law. So, if you are not sure, check with the original author and get his permission to use it in your application.
3.Review other relevant information.
a. If the BOM includes CVE information you may want to consider updating your component if there are known vulnerabilities.
b. Check the versions to make sure you are using the best, up-to-date version for your application.
c. Double check the usage information. While it may not be important today, six months down the road it may be important to know where a component is used and whether it was modified. It is easier to locate the information now than later. Listed above are some potential next steps to include in the review process. But, before moving on to other potential next steps, consider what an OSS BOM is NOT.
An open source BOM does not prescribe what to do. It is not a compliance checklist; it does not reveal potential risks associated with the use of OSS. It does not disclose if you have done anything wrong. And it certainly does not tell you if you are in trouble from a compliance perspective. As the old saying goes, it is “just the facts, ma’am.”
But, the information contained in a BOM is extremely valuable. It is the basis for compliance, tracking third-party components in your applications, and keeping your product secure and up-to-date.
Regardless of how you do it, by simply asking your developers for a list, or performing an in-depth scan and analysis using third-party scanning tools or services, creating an OSS BOM can be a valuable and important step in managing the development of your application.
What are some other questions you may have about managing OSS in your development?