The Definitive Guide to Software Bill of Materials

What Exactly is a SBOM (Software Bill of Materials)?

A SBOM (Software Bill of Materials) is a comprehensive inventory of all the components, dependencies, and libraries used in the development process of creating a software product or application.

The origins of the SBOM can be traced back to the manufacturing and supply chain management industries, where the concept of a "bill of materials" has been used for decades to track the components that go into the production of physical goods.

In the context of software, a SBOM provides a transparent and accountable record of all the software elements that make up an application, including open-source and third-party components.

It is a crucial compliance and security tool for many software component suppliers, as it can help organizations identify and manage potential security vulnerabilities in their software component supply chain.

Additionally, SBOMs are often a required item for many regulatory and compliance frameworks.

What Information Is Included in a SBOM?

The information included in a SBOM typically includes:

1. Component names: The names of all the components used in the software, including libraries, frameworks, and modules.
2. Version numbers: The version number of each component used in the software.
3. License information: The license of each component, including whether it is open source or proprietary.
4. Dependencies: The dependencies between the various components, including which components require other components to function.
5. Hash values: Hash values or checksums for each component to ensure their authenticity and to prevent tampering.
6. Author and supplier information: Information about the authors and suppliers of each component.
7. Vulnerabilities: Information about known vulnerabilities in each component.
   

What Is the Legislation Around SBOMs?

There have been various initiatives and guidelines promoting the use of SBOMs to improve software security and supply chain transparency in software applications.

For example, in the United States, the Cybersecurity and Infrastructure Security Agency (CISA) issued a Binding Operational Directive (BOD) in May 2021 that requires all federal government agencies to provide SBOMs for any software products they purchase or develop. The BOD also encourages software vendors to provide SBOMs as part of their standard offerings.

In the European Union, the European Union Agency for Cybersecurity (ENISA) published a report in 2020 on the use of SBOMs to improve software supply chain security. The report recommends that SBOMs should be included in contracts between software vendors and customers, and that SBOMs should be exchanged as part of software procurement processes.

Who Within an Organization is Responsible for Maintaining the Company's SBOM?

The responsibility for producing and maintaining a company's SBOM may vary depending on the organization's structure and size.

In general, the following roles may be involved in producing and maintaining a SBOM:

1. The Software development team: The software development team is responsible for creating the software and its components, and they may be responsible for creating an initial SBOM.
2. IT security team: The IT security team is responsible for assessing and managing cybersecurity risks and may be responsible for reviewing the SBOM to identify any vulnerabilities or potential security issues.
3. Procurement team: The procurement team is responsible for acquiring software and hardware products for the organization and may be responsible for requesting SBOMs from vendors as part of the procurement process.
4. Compliance team: The compliance team is responsible for ensuring that the organization complies with relevant laws, regulations, and industry standards, and may be responsible for reviewing the SBOM to ensure compliance with licensing requirements.
5. Quality assurance team: The quality assurance team is responsible for ensuring that the software meets the organization's quality standards and may be responsible for reviewing the SBOM to ensure that all components are properly tested and validated.
   

Who Outside of an Organization May Request to Review a SBOM and Why?

There are several parties outside of an organization that might request to review a SBOM, including:

1. Customers: Customers may want to review a SBOM to ensure that the software they are using is secure and does not contain any known vulnerabilities or open source components that may be subject to licensing or security risks.
2. Regulators: Regulators may require a SBOM as part of compliance requirements, especially for industries with specific regulatory standards, such as healthcare, finance, or government/military.
3. Suppliers and partners: Suppliers and partners may request a SBOM to understand the composition of the software they are integrating with their own products or services.
4. Independent security researchers: Independent security researchers may request a SBOM to perform vulnerability assessments and penetration testing to identify any security issues.
5. Open source communities: Open source communities may request a SBOM to ensure compliance with open source licensing requirements and to identify any potential security issues.

The reasons for reviewing a SBOM may vary depending on the party requesting it. In general, a SBOM can provide transparency about software dependencies involved and help ensure that software is secure and compliant with relevant regulations and industry standards.

It can also help build trust with customers, partners, and regulators by demonstrating a commitment to software supply chain security and transparency.

Should I Have a SBOM in My Company?

Having a SBOM is often tedious and burdensome for software developers to develop, requiring input from many different parties, as mentioned above.

However, producing and maintaining an up to date software bill of materials can provide several valuable benefits for an organization:

1. Improved security: A SBOM can help identify and manage security risks associated with software components by providing a clear understanding of what components are included in the software and any known vulnerabilities or patches.
2. More streamlined compliance: A SBOM can help ensure compliance with open source licenses and other regulatory requirements.
3. Increased supply chain transparency: A SBOM can provide transparency into the software supply chain, helping organizations identify potential risks and vulnerabilities in third-party components.
4. Better risk management: A SBOM can help organizations identify and manage risks associated with software components, enabling them to make informed decisions about software procurement, development, and maintenance.

What Standards Exist for Creating a SBOM?

SPDX:

The Software Package Data Exchange (SPDX) is an open standard for communicating software bill of materials information between parties in the software supply chain.

It provides a standardized format for SBOMs and includes licensing and security data.

Strengths of SPDX include its wide adoption and support from major organizations in the software industry.

Its weaknesses include the potential for confusion due to its extensive data model and lack of clear guidance on implementation.

CycloneDX:

CycloneDX is an open standard for describing software components and their metadata in a machine-readable format.

It provides a standardized format for SBOMs and includes information on licensing, vulnerability data, and other software metadata.
Strengths of CycloneDX include its simplicity and ease of use, as well as its integration with existing software development and security tools.

A weakness of CycloneDX is its limited adoption compared to other SBOM standards.

SWID:

The ISO/IEC 19770-2 standard for software identification tags (SWID) provides a standardized way to identify and track software installations across different systems and platforms.

It includes information on software components, their versions, and their relationships to other software components.

Strengths of SWID include its focus on software identification and its wide adoption by software vendors.

Its weaknesses include limited support for open source software and potential compatibility issues with existing software tools and systems.

ISO/IEC 27001:

The ISO/IEC 27001 standard for information security management systems includes guidance on supply chain security, including the use of SBOMs to manage software risks.

Strengths of ISO/IEC 27001 include its comprehensive approach to information security management and its international recognition.

Its weaknesses include its complexity and potential resource requirements for implementation.

SBOM Best Practices:

Regularly Update the SBOM

Once an SBOM is created by a software vendor, it is crucial to maintain and regularly update it as application components evolve. This includes incorporating code updates, bug fixes, new features, and other changes that occur across various teams. Real-time tracking is necessary to prevent the SBOM from becoming outdated.

Ensure Data Integrity

To maintain the integrity of the SBOM, it is important to have a comprehensive audit trail of all included information, such as version numbers and licenses. The data within the SBOM should originate from trusted sources and be verifiable by third parties.

Highlight Potential Issues Impacting Users

The SBOM should provide a clear overview of the current state of the application and outline necessary measures for ensuring proper security. Key elements of the SBOM should:

• Clearly present the existing files and components
• Identify actively used files and components
• Highlight security concerns and other issues that require attention

These issues could encompass restrictive open-source licenses, known vulnerabilities, and documented bugs or limitations in software components.

Distinguish SBOM Documents

It is essential to accurately identify SBOM documents, as multiple SBOM versions may exist for the same software. For instance, a new SBOM version might be released to rectify an error or communicate previously unknown vulnerabilities that were not included in the earlier version.

The latest SBOM version should be clearly indicated and contain complete, accurate, and up-to-date information about the software product.