Since its initial appearance in 2014 and following its formalization in 2021 under the auspices of the Biden administration, the concept of SBOM (Software Bill of Materials) continues to captivate attention within the cyber community. CISOs, CIOs and DevSecOps teams all wonder how to put it into practice and leverage it.

 

What is SBOM, and in what context does it come into play?

 The SBOM (Software Bill of Materials) is a formal inventory, typically in JSON, XML, or plain text format, designed to be machine-readable. It contains detailed information about the software components of a system, including their dependencies, attributes, and hierarchical relationships. The primary goal of an SBOM is to provide a comprehensive and up-to-date view of all the software elements composing an application or system (source: NTIA-Software-Bill-Of-Materials)

Like a physical product, software is a complex assembly of various elements. It includes internally developed code, third-party components (open-source libraries or modules subject to different licenses), as well as all the tools necessary for assembling the final product.

However, with each new vulnerability discovered by researchers or exploited by hackers, suppliers and buyers are faced with a crucial question: where do potential critical vulnerabilities lie within their product?

Today, Wavestone’s analysis formally attests that the SBOM is undeniably an essential element to address this issue.

 

Generation methods

A comprehensive technical analysis of tools available on the market has revealed the methods for generating Software Bill of Materials (SBOMs).

Three main sources emerge for creating a SBOM:

• Binary Code (compiled)
• Project Source Code
• Image Container, generated by platforms such as Docker.

These three sources can produce a file compliant with established standards, including SPDX and CycloneDX. However, it is essential to note that not all tools support these three inputs uniformly.

The technical challenge lies in decompiling binary code, which can sometimes impede its integration. In such cases, the search for specific predefined indicators within the code proves to be an effective method for identifying most of hierarchical interdependencies in an appropriate format.

Types of Inputs for Generating an SBOM

Despite these code extraction and analysis techniques, data completeness is not guaranteed, and additional verification must be considered.

 

Facilitated generation but an exploitation that remains to be determined, posing numerous unanswered questions

 The creation of an SBOM has been significantly simplified due to the presence of major players specialized in the market, such as Dependency Track, Adolus, and Fossa, to name a few. Additionally, well-established Software Composition Analysis (SCA) tools within our clients’ development teams now offer the capability to generate and read an SBOM.

Generating it is no longer a major challenge today, thanks to the implementation of the standards mentioned earlier. They facilitate automated SBOM generation by providing clear guidelines on how information about components should be structured and presented. Moreover, many software development and supply chain management tools now natively integrate SBOM creation.

However, the systems designed to analyze SBOMs are not yet fully mature. Clients receiving these inventories often face questions about how to use and share them with other parties. Furthermore, to this technical issue, organizational challenges are added, as the framework for use between organizations has not yet been clearly defined.

Nevertheless, stakeholders are actively working to establish a secure integration architecture for these SBOMs within their CI/CD pipelines.

Currently, obtaining a reliable SBOM from a third party remains a challenge. Concerns about exchange and sharing arise as soon as this topic is addressed. The diversity of contracts with suppliers, who seek to protect their intellectual property, and the challenge of centralization pose hurdles to the content of such inventories. Each inventory is developed heterogeneously, without follow-up or a uniform regulatory framework imposed. From a technical standpoint, each entity has the freedom to report the information of their choice.

As of now, we observe that pioneers in the field are opting for internal generation of their SBOMs, including for third-party software. This approach offers greater control over the quality and specificity of data, underscoring the need for more detailed regulation and stricter standards to ensure the reliability of software inventory exchanges.

 

The SBOM Integrated into the Core of Your Software Processes

All these gaps have prompted the design of an optimal, theoretically state-of-the-art process to integrate an SBOM into a CI/CD pipeline, a process that can be broken down into a few steps.

1. Creation of an SBOM Generation and Collection Space, Automating the collection of these data to ensure their accuracy and completeness.
2. Storage of SBOMs in a Repository, Configuring a centralized repository to store all generated SBOMs. This could be a version control repository or a suitable data storage system.
3. Distribution of an SBOM Package upon Client Request, Ensuring that SBOMs are easily accessible, and clients can securely retrieve them on demand.

                                   Projection on the Integration of an SBOM within a Software Supply Chain

This theoretical outlook paves the way for the automation of the process of generating, storing, and disseminating inventories and vulnerability reports.

This will provide stakeholders with the ability to:

• Receive real-time SBOMs and vulnerability reports.
• Authenticate the legitimacy of received artifacts (image containers, documents, etc.).
• Establish trust and validation through transparency at the heart of the software production process.

 

A Bright Future for SBOM?

 Political entities are becoming aware of the level of unpreparedness of their infrastructures in the face of increasing cyber threats. In this context, SBOM is increasingly seen as an effective means to enhance responsiveness to vulnerabilities that could simultaneously affect many companies.

Even though the market is not quite ready for a widespread transition to the use of this solution, it is common for regulation, even if it may seem arbitrary, to profoundly influence the trajectory in a new direction.

It is likely that Europe will eventually converge towards the regulation established in the United States, even though it still seems to be in a preliminary and incomplete stage, especially concerning the mechanisms for sharing and exchanging these inventories.

In the current context, stakeholders are compelled to reassess their priority criteria. It will be important to have data on software composition, the origin of its components, their source, known vulnerabilities, and to trust the production and quality control process.

However, it is necessary to bring back to the agenda the series of challenges they generally face:

• Incomplete or lacking data, the absence of comprehensive data on software composition can make risk assessment difficult.
• Ad hoc approaches for data sharing, non-standardized methods and improvised approaches for information sharing can make communication inefficient and unreliable.
• Additional costs for data collection and maintenance, Collecting, verifying, and updating information on software composition can incur additional costs.
• Lack of standardization, the lack of standards in collecting and sharing data makes it difficult to compare and analyze information among different stakeholders.
• Governance and data privacy, managing sensitive data on software composition raises concerns about its confidentiality, integrity, and availability.

In conclusion, the SBOM serves as a vital ally for the security of your products, enabling transparency, risk reduction, and informed decision-making throughout the software development lifecycle.