Producing and maintaining a Software Bill of Materials (SBOM): challenges and future directions

In this article, find out why Software Bills of Materials (SBOMs) have become essential to Open Source and cyber compliance.

Faced with the growing complexity and pace of digital innovation, almost no software is now developed without relying on components written and published by third parties. This practice is made possible and easier both legally, through the use of Open Source licences on those components, and technically, through community platforms that allow these dependencies to be published and updated. It nevertheless introduces a real risk for vendors and manufacturers, since a standard web project commonly carries several tens of thousands of dependencies.

Given the legal, technical and strategic risk that such use generates, it is now essential to put in place processes that make it possible to generate an inventory of all these dependencies, so that their use by the organisation can be validated according to each context of exploitation.

The development of standards for Software Bills of Materials (also known as SBOMs), supported by recent regulation, is part of this dynamic. A set of complementary initiatives (tools, regulations, good practices) now draws on the potential of these shared repositories within the development chains of digital products.

SBOMs: a recognised contribution to greater software transparency and security

SBOMs are an exhaustive inventory of all the components of a digital solution. They complement the traditional Bills of Materials used in hardware or for the certification of sensitive software. By professionalising development practices, making SBOMs systematic marks a significant step towards better software transparency and security. They make it possible to identify each version of each component used to run each application.

In practice, each SBOM lists all third-party components and enriches them with additional information about the component itself (unique identifier, status), depending on the needs and contexts at hand: security, intellectual property, export control and so on.

All this information is essential to obtain a clear and accurate picture of the software, so that risks can be precisely assessed for each context of exploitation.

Automated processing of this information then addresses the growing challenges that digital technology presents for software manufacturers and users. It allows security flaws or potential risks to be traced more quickly so they can be remediated, but also makes it possible to list all the obligations arising from a particular use, in terms of Open Source compliance, or to check that the licences of the various embedded components are compatible with one another.

SBOMs: a growing obligation driven by trust

In an approach that aims both to support national digital players and to protect them from risky practices, a growing number of national regulations make the design, and sometimes the delivery on request, of SBOMs mandatory for any digital product placed on their market.

Several structuring regulatory texts have imposed certain practices:

• in the United States, in May 2021, the federal government’s Executive Order 14028 “Improving the Nation’s Cybersecurity” highlighted the critical role of the SBOM in managing the risk of software flaws and vulnerabilities, and requires SBOMs to be produced and delivered for any software developed under a federal contract.
• in Europe, the publication of the Cyber Resilience Act (CRA) at the end of 2024 (see our work on the subject) requires SBOMs to be produced and transmitted at the request of the relevant supervisory body in each country, or case by case at customers’ request, so as to take into account the sensitive data these documents represent.

These practices are spreading to other regions, whether in binding form or as recommendations, such as the introductory guide to SBOMs published in 2023 by the Japanese Ministry of Economy, Trade and Industry to help companies become familiar with the concept and strengthen their cybersecurity.

These inventories will therefore make it possible to address cyber compliance and legal compliance requirements with greater precision.

Providing evidence of that control, including the safety of the components used, will become a requirement no player can escape. But in practice, what does building and managing an SBOM involve?

In practice, which implementations exist today and which are possible?

SBOMs are a nomenclature associated with a set of standards and formats, which are themselves tied to management tools.

Two main file formats are commonly used today to list the third-party dependencies of a project. Each has specific features linked to the field in which it was developed, to the complexity of the answers to be provided and to the wide diversity of economic players involved in these questions. A gradual convergence is emerging, even though their purposes differ:

• coming from the security field, the CycloneDX format was developed by OWASP (Open Worldwide Application Security Project) to strengthen software supply chain security and to automate the analysis of SBOMs.
• coming from the Open Source compliance field and supported by the Linux Foundation, the SPDX format (Software Package Data Exchange) promotes transparency and traceability across the many components and dependencies of a piece of software through a precise description of each element. Among other things, this makes it possible to verify compliance between the licences of the components within a piece of software.

In addition, these formats draw on a number of other standards, whether de facto or formally standardised, that make the unique identification of components easier. This is the case of Package URLs (PURL) used for Open Source dependencies, or of SWID tags used to attach licence information to certain commercial software, as well as of Open Source licences themselves, the SPDX License List being an integral part of the SPDX specification and used by both the SPDX and CycloneDX formats.

Around these formats, a set of SBOM management tools has grown up, each with its own specific features and lines of analysis.

Future directions for SBOMs and their management environment

The environments in which SBOMs are produced and analysed are still too heterogeneous. As things stand, each organisation needs to understand the SBOM life cycle in order to make automatic generation processes easier at its own scale. Harmonisation and convergence are desirable in the longer run, but they will require a proper understanding of the specific features of each development language.

From the point of view of SBOMs themselves, which can potentially list any type of information, there is also the question of what can usefully be included and what cannot. Information on patents or on cryptographic arrangements, for instance, can be useful for certain specific cases within the existing standards (see the work carried out around PatentBOM and CryptoBOM). The development of AI will very likely lead to other dimensions being taken into account as well. In the same vein, organisational and geopolitical parameters remain insufficiently, or not at all, taken into account: traditional SBOMs offer a technical inventory without considering the human dimension of Open Source communities, even though it is essential in assessing the resilience and sustainability of the solutions used.

A final challenge is the SBOM management environment itself and the associated tooling. Even though SBOM standards are open, most management tools remain proprietary and address specific issues. What is currently missing is an open and interoperable SBOM management chain that can be used across a diversity of situations. These questions are among the key issues for inno3 and all its partners, particularly around the deployment of Hermine FOSS and its current and future features.