What is xBOM?
In the context of Spectra Assure, the Extended Bill of Materials, or xBOM for short, is a comprehensive inventory of all building blocks of a software product throughout its development lifecycle. Unlike a traditional Software Bill of Materials (SBOM), xBOM lists all components and dependencies, services, machine learning models, and cryptographic assets, while also providing some additional information on each. This includes relationships between different parts of an application, as well as information about licenses, copyrights, security references, and more.
The Spectra Assure platform unpacks software builds, release packages, and containers to create an xBOM and displays this information on pages under the Bill of Materials category of the SAFE report. This information can be exported in the CycloneDX report format and later imported into databases or other external tools. The SPDX report format includes all Bill of Materials formats except CBOM.
What does xBOM include?
The Extended Bill of Materials goes beyong a traditional Software Bill of Materials (SBOM) by covering more components and providing deeper insights into each component and the relationships between them at different stages of the SDLC.
In other words, xBOM covers the following:
Each Bill of Materials that is included into an xBOM serves a different purpose depending on the context and the type of a product you're developing.
SBOM
A Software Bill of Materials, or SBOM for short, is a part of an xBOM that includes a machine-readable inventory of all components and dependencies that make up a software package and are involved in its lifecycle.
Even though the SBOM is focused on software components and dependencies, it also captures their hierarchical relationships and displays information about licenses, copyrights, and security references in a standard data format. This simplifies information sharing among various software publishers and buyers along a software supply chain.
An SBOM, with its clearly documented software components, increases trust into the particular software and enhances its transparency. It also helps reduce supply chain risk by facilitating identification of potential changes, vulnerabilities, and other software quality issues.
SaaSBOM
A Software as a Service Bill of Materials, or SaaSBOM for short, is a part of an xBOM that is used to track components and dependencies specifically related to the SaaS infrastructure, including third-party cloud services and APIs.
This Bill of Materials is much more than a simple inventory of all services included in an application. It also captures dependencies, service endpoints, and data classifications, as well as reliance on other services and the directional flow of data between them, making it more transparent than an SBOM.
With SaaSBOM, users get a better insight into the dynamic relationships between the services their product integrates with. It allows them to check the level of security of those third-party services, as well as identify and more effectively manage risks regarding insecure APIs, vulnerable data exchanges, and misconfigured services. As a result, users can confidently make more informed decisions on what they include in their applications.
ML-BOM
A Machine Learning Bill of Materials, or ML-BOM for short, is a part of an xBOM that offers a detailed inventory of all datasets, models, and configurations for AI and machine learning systems.
This transparency allows stakeholders to assess whether the data is representative or if there are any biases in the model’s training data. Clearly documented components can also help identify risks related to model security, which includes any potential vulnerabilities or insecure elements that could be exploited.
With an ML-BOM, you also get a clear overview of where the data is sourced from and how it is processed, ensuring that the data has been collected and used in an ethically responsible way. This helps detect any data integrity issues, such as incorrect or incomplete data. It also ensures that the data is trustworthy and that any data quality issues can be quickly identified and amended.
Having all important information on the ML models used in a software in one place builds trust with users and stakeholders by ensuring that the AI's actions, decisions, and processes can be traced, explained, and held to specific standards.
CBOM
A Cryptography Bill of Materials, or CBOM for short, is a part of an xBOM that offers a detailed inventory of all cryptographic assets in a particular product. This includes cryptographic algorithms, tokens, certificates, and keys that are implemented within a system, as well as how they relate to software components.
This level of detail helps organizations ensure their encryption methods are secure and remove any outdated algorithms or expired certificates. It also makes it easier for organizations to comply with cryptographic policies and standards and gives them better insight into their overall security posture and cryptographic dependencies.
CBOM supports post-quantum cryptography (PQC) initiatives and helps track and ensure the use of cryptographic methods which are resistant to any threats that could potentially break current encryption systems.
BOV
A Bill of Vulnerabilities, or BOV for short, is a part of an xBOM that offers a comprehensive inventory of known vulnerabilities within an application.
The BOV includes detailed descriptions of each identified vulnerability, outlining its technical nature, the affected components, and its potential impact on an organization. It also associates the identified vulnerabilities with CVE identifiers and categorizes the vulnerabilities by severity, which helps organizations prioritize their remediation efforts. Moreover, the BOV includes recommendations for mitigation or patching, guiding organizations on how to address vulnerabilities more effectively.
This structured approach simplifies the exchange of vulnerability information, which also improves collaboration between teams. It also allows organizations to maintain compliance with regulatory standards, ensuring that known vulnerabilities are accounted for and addressed in a timely manner.
VEX
A Vulnerability Exploitability eXchange, or VEX for short, is a part of an xBOM that focuses on the exploitability aspect of vulnerabilities. In other words, it shows whether a vulnerability can be exploited, provides information on how specific vulnerabilities can be exploited, and offers strategies for mitigating risks.
This level of specificity supports timely decision-making by helping organizations understand which vulnerabilities pose significant risks and require immediate attention. It allows organizations to allocate their resources more effectively, minimizing unnecessary remediation efforts, and ensuring that critical vulnerabilities are prioritized.
The data is provided in a machine-readable format, facilitating the exchange of information related to vulnerabilities and enabling organizations to make informed decisions about their security strategies. This is especially valuable in complex environments, where vulnerabilities might not be directly exploitable but could still have an impact on an organization.
Why is xBOM important?
Having access to all information contained in an xBOM offers:
Enhanced security. Allows teams to monitor vulnerabilities in third-party components and ensures that any identified security issues, as well as outdated or vulnerable components are addressed promptly.
Ensured compliance. Ensures compliance with legal or regulatory requirements, which in turn accelerates audits.
Software transparency. For software teams, an xBoM enhances visibility into all parts of a software, facilitating the processes of selecting components or troubleshooting potential issues. In case of open-source projects, it helps maintain transparency for contributors and users.
Dependency management. By tracking dependencies, an xBoM ensures that developers understand how different software components interact, making it easier to manage upgrades and maintain compatibility across versions. It also helps prevents conflicts caused by incompatible dependencies.