Bill of Materials (BOM)

Product assembly needs to be organized and uniform or else it can quickly get out of hand. It would be disastrous for a company to release products that have differences from one another. The same rule applies to software development. 

If each user gets a slightly different app from what another receives, there may be incompatibility issues, inconsistent performance, and other unwanted behavior. To prevent this from happening, you can commit to listing a Bill of Materials (BOM) for every product you develop. 

In this glossary article, we describe the bill of materials, it’s composition, and some examples for you to learn from.

What is a Bill of Materials?

A BOM is a record of the raw materials, components, and instructions required for the production and repair of a product.

When viewing a BOM, you will find the completed product at the top of the list. The individual components are at the end of the list.

When applied to software development, a BOM describes the third-party or open-source code and dependencies used for creating software. It will also take note of the licenses, version, and patch status of each component used in the software. 

Through a BOM, developers have an easy access list of the building blocks of their program. This facilitates rebuilding the program, if necessary, and can help when patching or updating the software. Additionally, a BOM can help project managers ensure that their software complies with copyright laws and government regulations—hence, the BOM section on licenses. 

What is in a Bill of Materials? 

A software BOM will contain the components necessary for software to operate. A BOM must contain these details for several reasons including software dependencies and to avoid legal repercussions.

Open-Source or 3rd Party Components

Most software developers will rely on open-source components when developing their programs. The reason open-source components are preferred over writing new code is the time factor. Having to code all the tools necessary to create software takes time. All that time can be used for working on the project itself.

Having established that, the reason why it’s important to list these components in a BOM is for dependencies. Your program won’t be able to function without the open-source components. If you need to recreate your software, you won’t be able to replicate the same product if you don’t have a list of the necessary components. 

For example, if your team somehow loses data or encounters a fatal bug, they wouldn’t be able to recreate the program. Listing open-source components in the BOM can alleviate this issue.  Additionally, it provides transparency, letting consumers know about everything used when creating software. 

Open-Source Versions 

For similar reasons to the previous section, it’s necessary to list which version of each component was used when creating your software. 

Component functionality and compatibility often change with different versions. For instance, your team might have used a component that is two versions behind the latest update. The component version they used might include functionality absent in the latest release. Therefore, if a BOM doesn’t describe the correct version of a component, it might be impossible to reproduce the software.

Lastly, it allows developers to identify vulnerabilities. If someone discovers that a version of a component used in your program contains security exploits, it will be easy to patch this out if you have it listed in your BOM. Otherwise, you, your team, and your users may never know that the program has security vulnerabilities. 

Open-Source Licenses

Just because a component is open-source, that doesn’t mean you can use it for your software without crediting the license holder. Depending on the licensing agreement, your company can be at risk of litigation. 

To better understand open-source licenses, and avoid liability, here are the different types of licenses: 

• Public Domain - The component is free to use and modify without restriction.
• Permissive - This type of license allows for reproduction and modification with minimal restrictions.  
• Copyleft - These are also known as restrictive licenses. You can modify or redistribute the code as long as you comply with the restrictions based on the license agreement. There are 2 commonly used licenses under Copyleft: 
  • GPL 3 (General Public License)
  • AGPL 3 (Affero General Public License)

Abiding by and listing the open-source licenses in your BOM will protect you from legal repercussions. 

Examples of Software Bill of Materials

One of the formats for BOMs that is gaining popularity is SPDX by the Linux foundation. The goal of the SPDX project is to standardize BOMs across all software developers. This allows easier compliance with government regulations and licensing agreements. With a standardized format, a software BOM is also easier to understand. 

Bill of Materials: For Better Software Development Documentation

Documentation is important in every facet of business—including software development. Through the implementation of a BOM, your team can have an easier time addressing software vulnerabilities and can ensure your program is compliant with licensing agreements and government regulations.