Qu’est-ce qu’une SBOM ? La nomenclature des logiciels

Pourquoi une SBOM est indispensable

Les logiciels modernes reposent en grande partie sur du code tiers : des bibliothèques open source, des frameworks et des dépendances qui, à leur tour, en intègrent d’autres. Sans une nomenclature détaillée, rares sont ceux qui savent exactement ce que contient un produit. Cette opacité est devenue un problème majeur avec Log4Shell, lorsque la bibliothèque Log4j, largement utilisée, a révélé une faille critique.

La question cruciale qui s’est alors posée dans chaque entreprise était : quelles applications utilisent Log4j ? Une SBOM (Software Bill of Materials) correctement tenue à jour par produit répond à cette interrogation en un clic. Sans elle, il faut parcourir manuellement l’ensemble du parc logiciel. La SBOM transforme une recherche qui pouvait prendre des jours en une vérification ciblée.

Les critères d’une SBOM utilisable

Une SBOM (Software Bill of Materials) ne se résume pas à un simple PDF joint. Pour qu’elle soit réellement utile, elle doit être lisible par machine et pouvoir être analysée automatiquement. Deux formats se sont imposés : SPDX, issu de l’écosystème Linux, et CycloneDX, développé dans le domaine de la sécurité applicative. Tous deux décrivent les composants, les versions et les relations sous une forme structurée.

L’actualité des données est également cruciale. Une SBOM créée uniquement au moment de la sortie d’une version et jamais mise à jour devient rapidement obsolète à chaque nouvelle mise à jour. La génération automatique dans le cadre du processus de build est donc recommandée, afin que chaque version dispose de sa propre liste de composants exacte. C’est seulement à cette condition qu’il est possible d’identifier de manière fiable les nouvelles vulnérabilités en les comparant avec l’inventaire existant.

Ce que change le Règlement sur la Résilience Cybernétique

Le Règlement sur la Résilience Cybernétique (RRC, règlement (UE) 2024/2847) impose aux fabricants de produits contenant des éléments numériques d’améliorer leur niveau de sécurité tout au long de leur cycle de vie. L’annexe I, partie II, exige explicitement que les fabricants produisent une SBOM (Software Bill of Materials) dans un format standardisé et lisible par machine, couvrant au minimum les composants et dépendances de premier niveau. Ce document fait partie de la documentation technique et doit être disponible pour les autorités de surveillance, sans pour autant être rendu public auprès des clients finaux.

Les exigences s’appliquent de manière progressive : les obligations de signalement des vulnérabilités exploitées activement et des incidents graves entreront en vigueur le 11 septembre 2026, tandis que les autres obligations du RRC s’appliqueront à partir du 11 décembre 2027. Pour les fabricants, cela signifie intégrer la SBOM comme une étape incontournable de leur processus de développement. Ceux qui l’adoptent tôt réduiront considérablement l’effort nécessaire pour se conformer aux futures obligations, contrairement à une intégration tardive.

Comment maintenir une SBOM opérationnelle en continu

Une SBOM ne déploie toute sa valeur qu’en phase d’exploitation. De nouvelles vulnérabilités apparaissent chaque jour : c’est pourquoi la liste des composants doit être comparée en continu avec les bases de données de vulnérabilités actualisées. Ce processus d’alignement automatique transforme la liste statique en un système d’alerte précoce capable d’identifier instantanément les produits concernés dès qu’une nouvelle faille est détectée.

Le concept VEX (Vulnerability Exploitability eXchange) s’est imposé comme une solution complémentaire. Il permet aux éditeurs d’indiquer si une vulnérabilité présente dans la SBOM est effectivement exploitable dans leur produit spécifique. Cela évite les fausses alertes lorsque, par exemple, une bibliothèque vulnérable est bien incluse, mais que le code concerné n’est pas activé. Associées à la SBOM, les données VEX offrent une vision réaliste de la surface d’attaque réelle.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.

Quelle est la différence entre SPDX et CycloneDX ?

Les deux sont des formats SBOM (Software Bill of Materials) établis. SPDX provient de l’écosystème open source et est largement standardisé, tandis que CycloneDX émane du domaine de la sécurité applicative. Tous deux sont lisibles par machine et adaptés à la comparaison avec les bases de données de vulnérabilités.

La loi sur la résilience cyber impose-t-elle les SBOM comme une obligation ?

Oui. L’annexe I, partie II, du règlement (UE) 2024/2847 impose aux fabricants d’établir une SBOM (Software Bill of Materials) lisible par machine et de la conserver dans la documentation technique. Aucune obligation de publication publique à destination des clients finaux n’est prévue.

Une SBOM suffit-elle à être générée une seule fois par produit ?

Non. Chaque version de logiciel devrait disposer de sa propre SBOM (Software Bill of Materials), car les composants et leurs versions évoluent à chaque mise à jour. L’idéal est de la générer automatiquement lors du processus de build.

Une SBOM permet-elle de se prémunir contre les attaques ?

Elle ne prévient pas une attaque, mais réduit considérablement le temps de réaction. En cas de nouvelle vulnérabilité, la SBOM (Software Bill of Materials) indique immédiatement quels produits sont concernés, évitant ainsi une longue recherche manuelle.

Faut-il exiger des SBOM (Software Bill of Materials) de la part des fournisseurs ?

Oui. Toute entreprise qui achète ou intègre des logiciels en externe devrait exiger une SBOM (Software Bill of Materials, en français : liste des composants logiciels) afin de maîtriser sa chaîne d’approvisionnement. Sans ces informations, une partie des risques reste invisible.

Les choix de la rédaction

À lireDeux vulnérabilités Joomla ajoutées au catalogue CISA KEV

Plus du réseau MBF Media

Digital ChiefsCinq endroits où les logiciels de chaîne d’approvisionnement échouentcloudmagazinFlexera 2026 : ce que la moyenne entreprise peut réellement assumer