Longtemps réservé aux spécialistes de la cybersécurité, le SBOM s’impose progressivement comme un élément central dans le développement, le déploiement et la maintenance des logiciels. Derrière cet acronyme encore peu connu du grand public se cache pourtant une idée relativement simple : savoir précisément de quoi est composé un logiciel.
À première vue, cela peut sembler évident. Pourtant, la réalité du développement moderne est bien différente. Les applications actuelles ne sont plus créées entièrement à partir de code développé en interne. Elles reposent sur un empilement de bibliothèques, de composants open source, de frameworks et de dépendances provenant parfois de dizaines de fournisseurs différents. Dans ce contexte, disposer d’une cartographie précise de tous ces éléments devient un enjeu majeur pour les entreprises.
C’est précisément le rôle du SBOM.
Une véritable carte d’identité du logiciel
Sommaire
Mais au fait, que signifie SBOM ? C’est l’acronyme de Software Bill of Materials, que l’on peut traduire en français par « nomenclature logicielle » ou « liste des composants logiciels ». Le concept est souvent comparé à la liste des ingrédients figurant sur l’emballage d’un produit alimentaire. Lorsqu’un consommateur achète un plat préparé, il peut consulter les ingrédients utilisés pour sa fabrication. De la même manière, le SBOM permet de connaître tous les composants qui constituent un logiciel.
Cette nomenclature peut inclure :
- les bibliothèques open source utilisées ;
- les composants propriétaires ;
- les frameworks ;
- les dépendances directes ;
- les dépendances indirectes ;
- les versions exactes des composants ;
- les licences associées ;
- les informations relatives aux éditeurs ou fournisseurs.
Le résultat est un document détaillé qui offre une visibilité complète sur la composition d’un produit logiciel.
Cette transparence est devenue essentielle car les logiciels modernes sont de plus en plus complexes. Une application web relativement classique peut aujourd’hui intégrer plusieurs centaines de composants externes. Certaines grandes plateformes numériques reposent même sur plusieurs milliers de dépendances logicielles.
Pour les équipes techniques, il devient alors difficile de conserver une vision exhaustive de l’ensemble des briques utilisées sans outil dédié.
Pourquoi les développeurs utilisent autant de composants tiers
Pour comprendre l’intérêt du SBOM, il faut d’abord comprendre comment les logiciels sont développés aujourd’hui : la majorité des développeurs ne réinventent pas la roue à chaque projet. Lorsqu’ils ont besoin d’une fonctionnalité spécifique, ils s’appuient généralement sur une bibliothèque existante. Cela permet de gagner du temps, de réduire les coûts et d’accélérer les cycles de développement. Par exemple, une simple application web peut utiliser une bibliothèque pour l’authentification des utilisateurs, une autre pour l’affichage graphique, une troisième pour la communication réseau et plusieurs autres pour la gestion des données.
Le problème est que chacune de ces bibliothèques peut elle-même dépendre d’autres composants. On parle alors de dépendances transitives ou indirectes. Très rapidement, un logiciel peut embarquer des centaines de briques technologiques différentes, parfois sans que les développeurs aient conscience de leur présence. Le SBOM apporte justement cette visibilité qui manque souvent dans les projets informatiques.
Un outil devenu indispensable pour la cybersécurité
Si le SBOM attire aujourd’hui autant d’attention, c’est principalement pour des raisons de sécurité. Les cyberattaques visant les chaînes d’approvisionnement logicielles se sont multipliées ces dernières années. Les entreprises cherchent désormais à mieux connaître les composants présents dans leurs systèmes afin de réagir rapidement lorsqu’une faille de sécurité est découverte.
L’exemple le plus emblématique reste la vulnérabilité Log4Shell révélée fin 2021. Cette faille touchait la bibliothèque open source Log4j, utilisée dans un nombre considérable d’applications Java. Lorsque la vulnérabilité a été rendue publique, de nombreuses organisations se sont retrouvées dans l’incapacité de déterminer rapidement si leurs logiciels étaient concernés. Certaines ignoraient même que Log4j était présent dans leurs systèmes, car la bibliothèque avait été intégrée indirectement via d’autres composants. Avec un SBOM à jour, il devient possible d’identifier presque instantanément les logiciels utilisant un composant vulnérable et de lancer les actions correctives nécessaires. Le gain de temps peut être considérable lorsque chaque heure compte.
Un atout pour la conformité et la gestion des licences
La sécurité n’est pas le seul intérêt du SBOM. Les entreprises doivent également gérer les licences associées aux composants logiciels qu’elles utilisent. Le monde de l’open source repose sur une multitude de licences dont les obligations peuvent varier fortement. Certaines imposent la publication du code source modifié. D’autres autorisent une utilisation commerciale sans contrainte particulière.
Sans inventaire précis, il devient difficile de vérifier la conformité juridique d’un produit logiciel. Le SBOM facilite ce travail en recensant les licences associées à chaque composant. Les équipes juridiques peuvent ainsi identifier rapidement les éventuels risques de non-conformité avant la commercialisation d’un produit. Cette dimension est particulièrement importante pour les éditeurs de logiciels qui distribuent leurs solutions à grande échelle.
Des formats standardisés pour automatiser les contrôles
Pour être exploitable efficacement, un SBOM doit être généré dans un format standardisé.
Deux standards dominent actuellement le marché :
- CycloneDX, développé à l’origine au sein de la communauté OWASP ;
- SPDX (Software Package Data Exchange), soutenu par la Linux Foundation.
Ces formats permettent aux outils de cybersécurité de lire automatiquement les informations contenues dans le document. Les scanners de vulnérabilités peuvent ainsi comparer les composants présents dans un logiciel avec les bases de données de failles connues et générer des alertes lorsqu’un risque est détecté.
En conséquence, l’utilisation du SBOM est aujourd’hui encouragée par de nombreuses autorités publiques. Aux États-Unis, plusieurs initiatives gouvernementales ont contribué à accélérer son adoption après plusieurs cyberattaques majeures ayant touché des infrastructures critiques.
