Table of Contents
When working on new software (or updating the existing one), you want to make sure that it’s properly secured and that all its components are 100% transparent and manageable. But considering that an average app has both first-party and third-party components, it can be incredibly hard to track and monitor them while ensuring that all regulatory and licensing requirements are met.
A software bill of materials, an SBOM for short, aims to bring transparency and visibility into the composition of your app and helps you maintain its performance and security. In this article, we explain what exactly a software bill of materials means, what it consists of, and how to create one.
What is SBOM?
A SBOM meaning can be defined as an inventory of all components of an app. This document lists such things as both first-party and open-source components, their dependencies, and metadata and helps organizations better manage the transparency of their software.
An SBOM comes from the BOM (bill of materials) concept in manufacturing. Similar to SBOM, a bill of materials is basically a list of all items (including their quantity) needed to create a certain product. Getting back to the IT industry, an SBOM helps organizations understand what kind of components are needed for the app and what might be a potential source of a threat or a vulnerability.
The importance of SBOM: security and transparency
Back in 2020, there were severe cybersecurity incidents (i.e., Apache Log4j security breach) that led to President Biden issuing the Executive Order on Improving the Nation’s Cybersecurity. The EO was issued in 2021 and was directed mainly at the companies operating in the governmental field. As you may guess, an SBOM was included in the list of recommendations, aimed at helping companies improve their safety and integrity.
A software bill of materials is important for any organization due to several reasons:
- Adds transparency to the software: with the help of an SBOM, organizations can easily see all components and dependencies of an app, as well as their sources.
- Facilitates tracking of vulnerabilities: by knowing what components are interdependent, developers can faster identify the source of a vulnerability and immediately implement preventive measures to safeguard the remaining components.
- Facilitates compliance with regulatory requirements: a transparent inventory of your software helps you better maintain and manage your compliance with needed regulations.
- Facilitates compliance with open-source software licenses: since open-source components are frequently used in most software applications, it is mandatory to comply with their licensing requirements. An SBOM helps understand software dependencies and corresponding licensing requirements and restrictions.
- Enables easier version control: since a new SBOM is required for each updated software version, it serves as a great way of tracking and managing software versions. Companies can instantly get access to information about previous versions and can perform rollbacks faster and more effectively.
- Standardizes the listing of dependencies: a software bill of materials adds consistency to the dependencies’ listing through using a single standard for their storage.
The minimal elements of an SBOM
To understand the SBOM concept even better, let’s look at its foundational areas, also known as minimal elements. These areas are listed in a report, issued by the National Telecommunications and Information Administration (NTIA), and explain what minimal elements are expected in an efficient SBOM.
According to the report, the SBOM minimal elements enable an evolving approach to software transparency. These elements are:
- Data fields
- Support for automation
- Processes and practices
Now, in more detail.
Data fields are the core of any software bill of material and contain information about every used and tracked component. The main goal of having data fields in place is to provide identification for all components of the app. The information that normally goes in the data fields includes:
- Supplier name: the name of the organization or a person who created this specific component;
- Component name: the name that was given by the original supplier;
- Component’s version: also given by the supplier;
- Unique identifiers: any relevant identifiers for this component;
- Dependency relationship: explanation of the relationship between the component and the software (or other components);
- Author: the name of a person or an organization that creates the SBOM information for this component.
Support for automation implies using automation for SBOM generation and data transfer. Considering the complexity of the SBOM management and generation process, automation allows easy scaling of the document across the organization and speeds up the data assembly process.
Lastly, processes and practices describe specific actions and concepts that need to be considered when working with the software bill of materials. A few examples are:
- Frequency: a new SBOM must be created every time when a component is updated with a new release (or build);
- Depth: a software bill of materials should contain all top-level components and their dependencies;
- Access control: describes the way an organization grants access to the SBOM and its data.
There are other practices listed in the original document – please see it for more information.
What is included in the software bill of materials?
We’ve already mentioned that an SBOM lists all components and dependencies of your software, including the open-source ones. Hence, you need to list down the following:
- Open-source and first-party components;
- Open-source licenses;
- Open-source and first-party versions;
- Vulnerabilities;
- Patch statuses of components.
Let’s look at each in a bit more detail.
Components
Software components can be defined as the building blocks of code that developers use to assemble an app faster and easier. These components can be either first-party (i.e., created by your company) or third-party, meaning, they were created by an external provider, correspondingly. Also, there can be open-source components that are publicly available for the use.
A software bill of materials usually presents the following information about components:
- A component’s name, version, and supplier;
- A component’s license.
The information on licensing is especially important, as it allows you to check whether your software adheres to the legal requirements and rights of use for a specific component.
Dependencies
A dependency is a relationship or a connection between the components. That means, components depend on each other for proper operation. And obviously, a vulnerability in one component may pose others at a risk.
This is why having a relevant SBOM in place is so important. Since this document lists all dependencies, it becomes much easier to manage them. As well, a proper SBOM helps to avoid dependency hell – a term that describes a situation where it’s impossible to add new components or programs to an app due to excessive complexity of existing dependencies.
Licenses
A license of a software component describes the way this component can be used, distributed, or customized. There are various types of licenses, including open-source proprietary ones, and each component may have its own licensing terms.
A company has to strictly follow the licensing terms for every component to adhere to its legal and regulatory requirements. Considering that there might be hundreds of components, the task seems a bit too much – this is where SBOM helps. Since the document lists all licenses for all used components, it becomes much easier to monitor and manage them and to ensure full compliance. Also, by knowing the licenses and their terms, organizations can make more informed decisions on the component selection and on the security of potential components.
Versioning
A new version of software is its modified or updated state. Each version has its own number, and version control is vital for tracking changes.
A new SBOM is normally created for every software version. In this way, developers can instantly see the changes made to a specific version, monitor software evolution, and effectively perform rollbacks or updates, if needed.
Integration with Software Development Lifecycle (SDLC) and SBOM creation
By now, a software bill of materials may seem overwhelming and way too complex. Luckily, it can be generated quickly and easily with the help of specialized SBOM software tools that analyze your software composition and generate an SBOM based on this analysis. But the question is when should you create a software bill of materials?
The main recommendation is that an SBOM generation should be automated as part of the CI/CD process. In this way, updated and relevant SBOMs will be produced with every code change. Also, such SBOMs can help you with establishing release gates to double-check if a software bill of materials contains any issues like unacceptable licenses or vulnerabilities.
In this way, you should consider generating an SBOM during the design and build stages of the SDLC. However, each stage of the SDLC will require a certain amount of interaction and work with the SBOM. Here is how it might look like:
- Project planning: at this stage, you can start selecting the suitable SBOM format and the tool for its generation and integration;
- Development: SBOM creation and integration happen during this SDLC stage;
- QA and testing: SBOM is used to ensure both software security and compliance with legal and regulatory requirements;
- Production: at this stage, a software bill of materials can serve as an additional proof of quality due to easy monitoring of software components.
As you can see, a software bill of materials is used throughout the software development lifecycle, but its actual integration happens during the design and development stage.
An SBOM example and main formats
Each project will require its own individual SBOM so we won’t be providing specific examples. Instead, let’s briefly talk about the main SBOM formats. There are two of them: SDPX and CycloneDX. Let’s look at each in more detail.
SPDX
SPDX stands for the Software Package Data Exchange. It is an open-source, machine and human-readable SBOM project by Linux and is perfectly suited for listing all your components, dependencies, and even security references. This format places special focus on license compliance and allows easy package data collection and sharing.
CycloneDX
CycloneDX is similar to SPDX and helps companies prepare an SBOM while also allowing for compilation of components and vulnerabilities. Since it was created by OWASP, no wonder this format focuses on cybersecurity. Another valuable feature of CycloneDX related to SBOM security is that it allows links to VEX (Vulnerability Exploitability Exchange), which aids in detecting vulnerabilities.
Challenges of SBOM adoption
Now that we’ve answered the “what is SBOM?” question, let’s see what challenges are associated with its implementation.
Integration with workflows and tools
To efficiently collect and update the information about your software, an SBOM needs to be integrated with your development processes and tools. This should be planned and executed in a careful and well-organized manner. Otherwise, the introduction of the software bill of materials can lead to the disruption of the development process.
Data consistency and accuracy
A software bill of materials needs to reflect the current state and components of the software. Hence, when any change is introduced to the application, it has to be reflected in the SBOM. Constant update and renewal of the software bill of materials may be too time and resource-consuming.
Security and intellectual property
The main goal of an SBOM is to add transparency to software development and to better manage all software components. But if your SBOM is shared across various (and external) stakeholders, it might compromise the security of your data or violate intellectual property rights. All these things need to be carefully considered before creating and distributing an SBOM.
Conclusion
A software bill of materials is gradually becoming a must-have for software development companies that care for transparency and better management of their software. It not only helps better maintain your apps but find vulnerabilities and eliminate risks in a much more efficient manner, which contributes significantly to the protection of data and reliability of your organization.
Comments