Software Bill of Materials (SBOM)

1. Overview

A Software Bill of Materials (SBOM) is a comprehensive, formal, and machine-readable inventory of software components and their dependencies. It is analogous to a list of ingredients on a food package, providing a detailed breakdown of the individual elements that constitute a piece of software. The primary problem that an SBOM solves is the lack of transparency in the software supply chain. Without an SBOM, organizations have limited visibility into the components that make up their software, making it difficult to identify and mitigate security vulnerabilities, manage license compliance, and assess overall software quality. The concept of a Bill of Materials has its roots in traditional manufacturing, where it has long been used to track the parts and materials used in the production of physical goods. The application of this concept to software has gained significant traction in recent years, driven by a series of high-profile software supply chain attacks, such as the SolarWinds and Log4j incidents. These events highlighted the critical need for greater transparency and accountability in the software ecosystem.

For organizations, the adoption of SBOMs is becoming increasingly important for several reasons. Firstly, it enables them to proactively identify and address security vulnerabilities within their software. By having a complete inventory of all components, organizations can quickly determine whether they are affected by a newly discovered vulnerability and take appropriate action. Secondly, SBOMs help organizations to manage their open-source license compliance obligations. Many software products are built using a combination of proprietary and open-source components, each with its own license terms. An SBOM provides a clear record of all open-source components and their associated licenses, enabling organizations to ensure that they are in compliance with all applicable terms and conditions. Finally, for the broader commons, SBOMs promote a culture of transparency and collaboration. By making the composition of software more visible, SBOMs enable all stakeholders in the software supply chain, from developers to end-users, to make more informed decisions about the software they produce, consume, and rely on.

2. Core Principles

1. Transparency: The primary principle of an SBOM is to provide full transparency into the composition of a software product. This means that the SBOM should list all software components, including both proprietary and open-source code, as well as their dependencies.
2. Machine-Readability: To be truly effective, an SBOM must be in a machine-readable format. This allows for the automation of SBOM generation, consumption, and analysis, which is essential for managing the complexity of modern software supply chains.
3. Standardization: The use of standardized formats for SBOMs is crucial for ensuring interoperability between different tools and organizations. The most common SBOM formats are Software Package Data Exchange (SPDX) and CycloneDX.
4. Accuracy: The information contained in an SBOM must be accurate and up-to-date. This requires a robust process for generating and maintaining SBOMs throughout the software development lifecycle.
5. Comprehensiveness: An SBOM should be as comprehensive as possible, including not only the names and versions of software components, but also other important metadata, such as license information, supplier details, and cryptographic hashes.

3. Key Practices

1. Integrate SBOM Generation into the CI/CD Pipeline: The generation of SBOMs should be an automated part of the continuous integration and continuous delivery (CI/CD) pipeline. This ensures that a new SBOM is generated every time the software is built, providing an up-to-date inventory of all components.
2. Use a Combination of SBOM Generation Tools: There are a variety of tools available for generating SBOMs, each with its own strengths and weaknesses. It is often best to use a combination of tools to ensure the most comprehensive and accurate results.
3. Validate SBOMs for Accuracy and Completeness: Once an SBOM has been generated, it should be validated to ensure that it is accurate and complete. This can be done using a variety of tools and techniques, such as comparing the SBOM to the actual contents of the software package.
4. Store and Manage SBOMs in a Central Repository: SBOMs should be stored and managed in a central repository, where they can be easily accessed by all stakeholders. This repository should also provide version control and other management features.
5. Share SBOMs with Downstream Consumers: SBOMs should be shared with all downstream consumers of the software, including customers, partners, and regulators. This enables them to make informed decisions about the software they are using and to manage their own security and compliance risks.
6. Use SBOMs to Drive Vulnerability Management: SBOMs are a powerful tool for vulnerability management. By combining the information in an SBOM with a vulnerability database, organizations can quickly identify all software products that are affected by a newly discovered vulnerability.
7. Leverage VEX for Vulnerability Triage: Vulnerability Exploitability eXchange (VEX) is a companion to SBOM that provides information about the exploitability of vulnerabilities. By using VEX, organizations can prioritize their vulnerability remediation efforts and focus on the vulnerabilities that pose the greatest risk.

4. Implementation

Implementing a Software Bill of Materials (SBOM) program requires a systematic approach that involves people, processes, and technology. The first step is to establish a clear policy and governance framework for SBOMs. This should define the goals of the SBOM program, the roles and responsibilities of different stakeholders, and the processes for generating, managing, and consuming SBOMs. Once the policy is in place, the next step is to select and implement the necessary tools. There are a variety of open-source and commercial tools available for generating, analyzing, and managing SBOMs. It is important to choose tools that are compatible with your existing development environment and that support the standard SBOM formats.

With the tools in place, you can begin to integrate SBOM generation into your software development lifecycle. This should be done as early as possible in the development process, ideally as part of the CI/CD pipeline. As you generate SBOMs, it is important to validate them for accuracy and completeness. This can be done by comparing the SBOM to the actual contents of the software package and by using a variety of analysis tools. Once you have a collection of SBOMs, you need to store and manage them in a central repository. This will enable you to track the composition of your software over time and to quickly identify any changes or new vulnerabilities. Finally, you need to establish a process for sharing SBOMs with your customers and other stakeholders. This will enable them to make informed decisions about the software they are using and to manage their own security and compliance risks.

Key considerations for a successful SBOM implementation include starting small and iterating, focusing on automation, and educating your developers. Common tools and frameworks include CycloneDX and SPDX for SBOM formats, and tools like Syft, Trivy, and Black Duck for SBOM generation. Success metrics for an SBOM program can include the percentage of software products with an SBOM, the time it takes to identify all products affected by a new vulnerability, and the reduction in the number of license compliance issues.

5. 7 Pillars Assessment

6. When to Use

• When you need to comply with regulatory requirements, such as the US government’s executive order on cybersecurity.
• When you want to improve your ability to identify and respond to security vulnerabilities in your software.
• When you need to manage your open-source license compliance obligations.
• When you want to provide your customers with greater transparency into the composition of your software.
• When you are involved in a merger or acquisition and need to assess the security and compliance risks of the target company’s software.
• When you want to improve the overall quality and security of your software development process.

7. Anti-Patterns & Gotchas

• Treating SBOMs as a checkbox exercise: Simply generating an SBOM is not enough. You need to have a process for using the information in the SBOM to improve your security and compliance posture.
• Relying on a single SBOM generation tool: No single tool is perfect. It is often best to use a combination of tools to ensure the most comprehensive and accurate results.
• Failing to keep SBOMs up-to-date: The software supply chain is constantly changing. You need to have a process for regularly updating your SBOMs to reflect these changes.
• Not sharing SBOMs with downstream consumers: SBOMs are most effective when they are shared throughout the software supply chain. By sharing your SBOMs, you can help your customers and other stakeholders to manage their own security and compliance risks.
• Ignoring the human element: Technology is only part of the solution. You also need to have the right people and processes in place to effectively manage your SBOM program.
• Assuming SBOMs are a silver bullet: SBOMs are a powerful tool, but they are not a silver bullet. They need to be used in conjunction with other security and compliance best practices.

8. References

1. [Software Bill of Materials (SBOM)

   CISA](https://www.cisa.gov/sbom)

2. [What Is a Software Bill of Materials (SBOM)?

   IBM](https://www.ibm.com/think/topics/sbom)

3. [What Is a Software Bill of Materials (SBOM)?

   Black Duck Blog](https.www.blackduck.com/blog/software-bill-of-materials-bom.html)