A complete guide about Computer IDs including a definition, what they're used for, approaches as well as challenges in generating and using them
Everything You Wanted to Know About Sboms and Were Too Afraid to Ask!
Intro: What is an SBOM, anyway?
An SBOM (Software Bill of Materials) is a comprehensive inventory of all the components, dependencies, and libraries used in 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, an 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, as it can help organizations identify and manage potential security vulnerabilities in their software supply chain. Additionally, SBOMs are often a required item for many regulatory and compliance frameworks.
What Information is Included in an SBOM?
The information included in an SBOM typically includes:
- Component names: The names of all the components used in the software, including libraries, frameworks, and modules.
- Version numbers: The version number of each component used in the software.
- License information: The license of each component, including whether it is open source or proprietary.
- Dependencies: The dependencies between the various components, including which components require other components to function.
- Hash values: Hash values or checksums for each component to ensure their authenticity and to prevent tampering.
- Author and supplier information: Information about the authors and suppliers of each component.
- 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.
For example, in the United States, the Cybersecurity and Infrastructure Security Agency (CISA) issued a Binding Operational Directive (BOD) in May 2021 that requires federal 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 an SBOM:
- 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.
- 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.
- 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.
- 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.
- 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 an SBOM and Why?
There are several parties outside of an organization that might request to review an SBOM, including:
- Customers: Customers may want to review an 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.
- Regulators: Regulators may require an SBOM as part of compliance requirements, especially for industries with specific regulatory standards, such as healthcare, finance, or government/military.
- Suppliers and partners: Suppliers and partners may request an SBOM to understand the composition of the software they are integrating with their own products or services.
- Independent security researchers: Independent security researchers may request an SBOM to perform vulnerability assessments and penetration testing to identify any security issues.
- Open source communities: Open source communities may request an SBOM to ensure compliance with open source licensing requirements and to identify any potential security issues.
The reasons for reviewing an SBOM may vary depending on the party requesting it. In general, an SBOM can provide transparency 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 an SBOM in My Company?
Having an SBOM is often tedious and burdensome 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:
- Improved security: An 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.
- More streamlined compliance: An SBOM can help ensure compliance with open source licenses and other regulatory requirements.
- Increased supply chain transparency: An SBOM can provide transparency into the software supply chain, helping organizations identify potential risks and vulnerabilities in third-party components.
- Better risk management: An 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 an 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.