Produire et maintenir une Software Bills of Materials (SBOM) : enjeux et pistes futures

Face à la complexité et la vitesse croissante des innovations numériques, quasiment plus aucun logiciel ne se développe sans faire appel à des composants écrits et publiés par des tiers. Cette pratique est rendue possible et facilitée tant d’un point de vue juridique (via l’usage de licences Open Source sur ces composants) que technique (au travers de plateformes communautaires permettant la publication et mise à jour de ces dépendances). Elle introduit néanmoins un risque réel pour les éditeurs et fabricants, car il n’est pas rare d’avoir plusieurs dizaines de milliers de dépendances dans un projet web standard.

Compte tenu du risque juridique, technique ou stratégique qu’un tel usage alimente, il est aujourd’hui indispensable de mettre en place des processus permettant d’une part de générer un inventaire de l’ensemble de ces dépendances afin de pouvoir valider leur usage par l’entreprise en fonction des contextes d’exploitation.

Le développement de standards en matière de Software Bills of Materials (aussi dit SBOM) — en français inventaires ou nomenclature des logiciels –, soutenu par la réglementation récente, participe à cette dynamique. Un ensemble d’initiatives complémentaires (outils, réglementations, bonnes pratiques, etc.) viennent exploiter le potentiel de ces référentiels partagés au sein des chaînes de développement des produits numériques.

Les SBOM : une reconnaissance de leur utilité pour une plus grande transparence et sécurité accrue des logiciels

Les SBOM constituent un inventaire exhaustif de l’ensemble des composants d’une solution numérique. Elles complètent les Bills of Materials traditionnelles utilisées dans le hardware ou pour les certifications des logiciels sensibles. Professionnalisant les pratiques de développement, la systématisation de SBOM représente une évolution significative pour une meilleure transparence et sécurité des logiciels. Ces SBOM permettent d’identifier chaque version de chaque composant utilisé pour faire fonctionner chaque application.

En pratique, chaque SBOM liste d’une part tous les composants tiers, qu’elle enrichit d’un ensemble d’informations complémentaires sur le composant en lui-même (identifiant unique, statut) en fonction des besoins / contextes tels que la sécurité, la propriété intellectuelle, le contrôle lié à l’exportation, etc.

L’ensemble de ces informations sont essentielles pour obtenir une image claire et précise du logiciel afin de pouvoir réaliser une estimation précise des risques pour chaque contexte d’exploitation.

Dans un second temps, le traitement automatisé de ces informations permet de répondre aux enjeux croissants que présente le numérique pour les fabricants et utilisateurs de logiciels : permettant ainsi de remonter plus rapidement aux failles ou aux risques éventuels de sécurité afin de les résorber, mais aussi lister toutes les obligations résultantes d’une exploitation particulière (en matière de conformité Open Source) ou encore de s’assurer de la compatibilité entre les licences des différents composants embarqués.

Les SBOM : une obligation croissante pour des motifs de confiance

Dans une démarche qui vise à soutenir les acteurs nationaux du numérique, mais aussi à les protéger de pratiques à risques, de plus en plus de réglementations nationales édictent comme obligation la conception, voire la livraison, de SBOM à la demande pour tout produit numérique commercialisé sur leur territoire.

Plusieurs textes réglementaires structurants sont ainsi venus imposer certaines pratiques :

• aux USA, en mai 2021, le décret 14028 du gouvernement américain « Améliorer la cybersécurité nationale » met en exergue le rôle critique du SBOM dans la gestion du risque de failles et de vulnérabilités logicielles et impose la production et la livraison de SBOM pour tout logiciel développé dans le cadre d’un marché fédéral.
• en Europe, la récente publication du Cyber Resilience Act (CRA) fin 2024 (voir notre étude sur le sujet) impose la conception de SBOM à transmettre à la demande de l’organisme de contrôle pertinent dans chaque pays ou au cas par cas à la demande des clients (afin de prendre en considération les données sensibles que représentent ces documents).

Ces pratiques se répandent dans d’autres régions, que ce soit sous une forme contraignante ou au stade de préconisation (tel le guide introductif sur les SBOM publié en 2023 par le Ministère de l’Économie, du Commerce et de l’Industrie japonais, afin d’aider les entreprises à se familiariser avec cette notion et renforcer leur cybersécurité).

Ainsi, ces inventaires permettront de répondre plus finement aux enjeux respectivement de conformité cyber et de conformité juridique.

Fournir des preuves de cette maîtrise, y compris l’innocuité des composants utilisés, sera désormais une exigence à laquelle nul acteur ne pourra se soustraire. Mais en pratique, qu’impliquent la constitution et la gestion d’un SBOM ?

En pratique, quelles mises en œuvre actuelles et possibles ?

Les SBOM représentent une nomenclature qui est associée à un ensemble de standards et formats, eux-mêmes liés à des outils de gestion.

Deux formats (de fichiers) principaux de gestion de SBOM sont aujourd’hui couramment utilisés pour lister les dépendances tierces d’un projet, chacun ayant des spécificités liées aux domaines dans lesquels ils ont été développés, à la complexité des réponses à apporter et la grande diversité des acteurs économiques impliqués dans ces questions. Une convergence progressive apparaît même si leurs vocations diffèrent :

• issu du domaine de la sécurité, le format Cyclone DX a été développé par l’OWASP (Open Worldwild Application Security Project) pour renforcer la sécurité de la chaîne d’approvisionnement logicielle et automatiser le processus d’analyse des SBOM.
• issu du champ de la conformité Open Source et soutenu par la fondation Linux, le format SPDX (Software Package Data Exchange) favorise une transparence et une traçabilité des nombreux composants et dépendances d’un logiciel par une description précise de chaque élément. Cela permet notamment de vérifier la conformité entre les licences des composants au sein d’un logiciel.

En complément, ces formats font appel à un certain nombre d’autres standards (de fait ou parfois normalisés) facilitant l’identification unique des composants (tels que les Package URLs PURL utilisés pour les dépendances Open Source ou encore les balises SWID permettant de rattacher aux licences de certains logiciels commerciaux) ou encore des licences Open Source (SPDX License List étant partie intégrante de la spécification SPDX, utilisée autant par le format SPDX que Cyclone DX).

Autour de ces formats, un ensemble d’outils de gestion des SBOM s’est constitué chacun ayant ses spécificités et ses axes d’analyse.

Pistes d’actions futures autour des SBOM et de leur environnement de gestion

Les environnements dans lesquels les SBOM sont produites et analysées sont encore trop hétérogènes. À ce jour, il est ainsi nécessaire pour chaque organisation de comprendre le cycle de vie du SBOM pour faciliter les processus de génération automatique de SBOM à son échelle. Une harmonisation et une convergence sont souhaitables à terme, mais cela passera par une nécessaire compréhension des spécificités propres à chaque langage de développement.

Enfin, et d’un point de vue des SBOM (qui permettent éventuellement de lister tout type d’informations), se pose la question de ce qui peut utilement être inclus ou non. Par exemple, des informations sur les brevets ou bien encore sur les modalités de crypto peuvent être utiles pour certains cas spécifiques au sein des standards existants (cf. travail autour de PatentBom et des cryptoBom). Ainsi, le développement de l’IA amènera aussi très certainement à prendre en considération d’autres dimensions dans les SBOM. Dans le même esprit, s’ajoute à cela une prise en compte encore insuffisante (voire inexistante) de paramètres organisationnels et géopolitiques : les SBOM traditionnelles proposent en effet un inventaire technique sans prendre en compte par exemple la dimension humaine des communautés Open Source, même si essentielle pour évaluer la résilience et la soutenabilité des solutions utilisées.

Enfin, un dernier enjeu est celui de l’environnement même de gestion des SBOM et des outils associés. Aujourd’hui, même si les standards des SBOM sont ouverts, la plupart des outils de gestion sont propriétaires et traitent de problématiques spécifiques. Il manque à l’heure actuelle une chaîne de gestion des SBOM ouvertes et interopérables pour pouvoir être employées dans une diversité de cas de figure. Ces réflexions font partie de problématiques clefs pour inno3 et l’ensemble de ses partenaires autour notamment du déploiement d’Hermine FOSS et de ses fonctionnalités actuelles et futures.