Un SBOM est un document complet et lisible par machine de tous les composants logiciels qui composent votre logiciel. Le terme vient de l'anglais Software Bill of Materials, traduit en français par nomenclature logicielle. Cette liste détaillée répertorie chaque bibliothèque, chaque dépendance et chaque composant tiers présent dans une application, avec sa version et sa licence.
L'idée paraît simple. La réalité l'est moins. Un logiciel moderne assemble des centaines de composants open source, eux-mêmes appuyés sur d'autres composants. Sans cette nomenclature logicielle, personne ne sait vraiment ce que contient le produit livré. Quand une vulnérabilité majeure surgit dans une bibliothèque très répandue, les équipes passent des jours à chercher si elles sont impactées. Un SBOM à jour répond à cette question en quelques minutes.
Cet article explique ce qu'est un SBOM, à quoi il sert, quels formats existent, comment le générer, et pourquoi le sujet devient nettement plus difficile dans les produits embarqués.
Qu'est-ce qu'un SBOM ?
Un SBOM est un artefact qui répertorie tous les composants utilisés pour créer un logiciel, dans un format structuré et exploitable automatiquement. Il permet de détailler chaque composant présent dans le produit final.
La comparaison classique reste celle des ingrédients sur un emballage alimentaire. Vous voyez ce que contient le produit, dans quelle proportion, et vous pouvez vérifier si un élément vous pose problème. La nomenclature logicielle joue le même rôle pour un logiciel.
Chaque entrée du SBOM contient plusieurs métadonnées essentielles. Le nom du composant, sa version exacte, son éditeur ou fournisseur, sa licence, et un identifiant unique permettant de le rattacher aux bases de vulnérabilités connues. Certains formats ajoutent des informations de provenance, des empreintes cryptographiques ou les relations de dépendance entre composants.
La différence avec un simple fichier de dépendances est importante. Un tel document contient ce que le développeur a requis. Le SBOM détaille ce qui se retrouve réellement dans le logiciel livré, y compris les dépendances transitives que personne n'a explicitement choisies.
Pourquoi le SBOM devient incontournable
Plusieurs facteurs ont fait passer la nomenclature logicielle du statut de bonne pratique à celui d'exigence.
Le problème de la chaîne d'approvisionnement logicielle
Un logiciel n'est plus écrit, il est assemblé. La majorité du code d'une application provient de composants open source et de logiciels tiers que l'équipe n'a pas écrits. Cette chaîne d'approvisionnement logicielle est devenue la principale surface d'attaque.
Les attaques récentes l'ont démontré. Compromettre un composant très utilisé permet d'atteindre des milliers d'organisations d'un coup. Sécuriser la chaîne suppose d'abord de savoir ce qu'elle contient.
La réponse
aux vulnérabilités
C'est l'usage le plus concret. Une nouvelle CVE est publiée sur une bibliothèque. Sans SBOM, chaque équipe fouille ses projets pour identifier les vulnérabilités éventuelles, un travail long et incertain. Avec un SBOM complet, une requête suffit pour savoir quels logiciels sont affectés et dans quelle version. Les données de vulnérabilité deviennent exploitables.
Cette capacité change la gestion des vulnérabilités. On passe d'une réaction artisanale à un processus mesurable et rapide.
La conformité
réglementaire
Le contexte réglementaire a accéléré le mouvement. Aux États-Unis, un décret présidentiel impose le SBOM aux fournisseurs de l'État fédéral depuis 2021. En Europe, le Cyber Resilience Act rend la documentation des composants obligatoire pour les produits comportant des éléments numériques. Le règlement européen s'applique progressivement jusqu'en décembre 2027, avec des obligations de signalement dès septembre 2026.
Pour un fabricant, la réglementation transforme le SBOM en livrable contractuel. Un client peut désormais l'exiger avant d'acheter.
La gestion
des licences
Un usage souvent sous-estimé. Chaque composant open source porte une licence, et certaines imposent des contraintes fortes sur le produit qui les intègre.
Une licence copyleft mal identifiée peut obliger à publier du code propriétaire.
Le SBOM offre la visibilité nécessaire pour vérifier la conformité juridique avant la mise sur le marché, pas après.
Les formats standardisés, SPDX et CycloneDX
Un inventaire n'a d'utilité que s'il est exploitable par les outils. Deux formats se sont imposés.
SPDX
SPDX, pour Software Package Data Exchange, est né à la Linux Foundation et constitue une norme ISO depuis 2021, référencée ISO/IEC 5962. Son origine explique son orientation. Il excelle sur la description des licences et la conformité juridique.
Le format SPDX existe en plusieurs représentations, notamment JSON, YAML et tag-value. Sa normalisation en fait le choix privilégié dans les contextes contractuels et réglementaires, où la référence à une norme reconnue simplifie les échanges.
CycloneDX
CycloneDX vient de la fondation OWASP et a été pensé dès le départ pour la sécurité applicative. Il gère finement les relations de dépendance, les composants de service, et s'intègre naturellement aux éléments d'analyse de vulnérabilités.
CycloneDX s'étend aussi au-delà du logiciel classique, avec des variantes pour le matériel et les modèles d'apprentissage automatique.
Lequel choisir ?
La question revient souvent.
En pratique, SPDX répond mieux aux besoins de conformité et de licence, CycloneDX aux besoins de sécurité opérationnelle. Beaucoup d'organisations génèrent les deux, la conversion entre formats étant possible avec les bons outils.
Le choix dépend surtout de ce que demande votre client ou votre réglementation.
Les outils de génération de SBOM : comment l'automatiser ?
La génération d'un SBOM ne doit pas être une charge manuelle : elle s'automatise entièrement au sein de vos pipelines de développement grâce à quatre grandes familles d'outils :
- Les scanners de dépendances (Analyse de configuration) : Ils lisent les fichiers déclaratifs de vos gestionnaires de paquets (package.json, pom.xml, etc.). Très rapides, leur exhaustivité dépend toutefois de la qualité de vos déclarations d'origine.
- Les inspecteurs d'artefacts (Analyse binaire) : Ils décortiquent directement l'artefact compilé (binaire, image Docker) pour identifier ce qui est réellement présent dans le produit final, y compris les dépendances omises ou injectées.
- L'outil phare : Syft est l'un des outils les plus répandus dans cette catégorie, capable de produire nativement les formats SPDX et CycloneDX.
- Les scanners de vulnérabilités : Ils consomment le SBOM généré pour croiser immédiatement chaque composant et chaque version avec les bases de données de failles connues (CVE).
- L'outil phare : Grype fonctionne en duo parfait avec Syft pour automatiser cette analyse de risque.
- Les plateformes CI/CD intégrées : Désormais proposées par les grands acteurs du développement logiciel (GitHub, GitLab...), elles génèrent automatiquement la nomenclature directement au cœur de la chaîne d'intégration continue.
L'enjeu du timing : générer au build, pas après !
Le moment où le SBOM est généré est décisif pour sa fiabilité. L'inventaire doit impérativement être produit pendant la phase de compilation (build).
À cet instant précis, le SBOM capture la photographie exacte et inaltérable de ce qui est livré au client. Une reconstitution effectuée a posteriori ne reste qu'une approximation incertaine.
Créer un SBOM en pratique
Créer un SBOM suit une démarche en quelques étapes :
1.
Commencez par identifier le périmètre.
Un SBOM par logiciel et par version, pas un document global qui mélange tout.
2.
Intégrez la génération dans votre chaîne de build. L'automatisation garantit que le SBOM reste à jour à chaque livraison, ce qui est la condition de son utilité.
3.
Vérifiez le résultat. Un premier SBOM révèle souvent des composants oubliés, des versions obsolètes ou des licences problématiques.
C'est le signe que l'exercice sert à quelque chose.
4.
Croisez ces données avec les bases de vulnérabilités connues pour obtenir un rapport exploitable par les équipes sécurité. Chaque vulnérabilité identifiée doit pouvoir être rattachée à un composant précis.
5.
Distribuez le SBOM à vos clients et partenaires selon le format exigé, et conservez un historique par version livrée.
6.
Complétez par un document VEX quand c'est pertinent. Ce format indique si une vulnérabilité présente dans un composant affaiblit réellement votre produit, ce qui évite d'alerter inutilement sur des failles non exploitables dans votre contexte.
Ce que contient un SBOM en détail
Un SBOM complet ne se limite pas à énumérer des noms de composants logiciels.
Chaque entrée doit fournir assez d'information pour être exploitable automatiquement.
- Le nom du composant et sa version exacte constituent le minimum. Sans la version, impossible de savoir si une vulnérabilité connue vous affecte, puisque les failles touchent des versions précises.
- L'identifiant unique permet de rattacher le composant aux référentiels publics. Les identifiants normalisés comme le PURL ou le CPE assurent que l'outil d'analyse reconnaîtra bien la bibliothèque, malgré les variations de nommage entre écosystèmes.
- La licence de chaque composant est indispensable pour vérifier la conformité juridique du produit livré.
- Le fournisseur ou l'éditeur indique qui maintient le composant, une information utile pour évaluer le risque d'abandon.
Les relations de dépendance montrent quel composant en appelle un autre. Cette structure d'arbre est ce qui distingue un vrai SBOM d'un fichier plat. Elle permet de comprendre pourquoi une bibliothèque se retrouve dans votre application alors que personne ne l'a demandée. - Les empreintes cryptographiques garantissent l'intégrité, en assurant que le composant analysé est bien celui qui a été livré.
Un SBOM détaillé offre donc bien plus qu'une énumération : Il fournit le contexte nécessaire pour évaluer les risques de sécurité liés à chaque élément du produit !
Les types de SBOM selon le moment de génération
Tous les SBOM ne se valent pas ! Et le moment de leur création change ce qu'ils contiennent.
Le SBOM de conception
décrit les composants prévus, avant même le développement. Il sert à anticiper les choix de licence.
Le SBOM de source
Pour ajouter une quatrième colonne, réduisez la taille de ces trois colonnes à l'aide de l'icône de droite de chaque bloc. Ensuite, dupliquez l'une des colonnes pour en créer une nouvelle en tant que copie.
Le SBOM de build
est généré pendant la compilation. C'est le plus fiable, puisqu'il observe ce qui entre réellement dans l'artefact produit.
Le SBOM issu d'une inspection binaire
examine le logiciel compilé. Il détecte les composants intégrés en dur, que les autres méthodes manquent, ce qui le rend précieux sur les produits anciens.
Le SBOM de déploiement
contient ce qui tourne réellement en production, en incluant les éléments d'environnement.
Pour un logiciel livré à un client, le SBOM de build reste la référence.
Pour un produit existant dont on a perdu la chaîne d'outillage, l'analyse binaire devient la seule option.
Générer un premier inventaire est facile. Le maintenir est un autre exercice !
Maintenir un SBOM à jour, les vraies difficultés
Chaque nouvelle version modifie les composants utilisés. Un SBOM figé perd sa valeur en quelques semaines. Les organisations qui réussissent traitent l'inventaire comme un artefact de build, régénéré automatiquement, versionné et archivé au même titre que le binaire livré.
Un SBOM à jour est la condition pour que les mises à jour de sécurité soient pilotées plutôt que subies.
L'autre difficulté tient à l'exploitation. Un SBOM qui dort dans un répertoire n'apporte rien : La valeur vient du processus qui l'exploite, de la détection d'une CVE à la décision de corriger, en passant par l'information des clients affectés.
Le troisième point concerne la distribution. Vos clients vont demander le document, dans un format qu'ils savent lire. Il faut donc décider comment le fournir, à qui, et à quel niveau de détail. Certaines entreprises hésitent, craignant d'exposer la composition de leur produit. Cette crainte se comprend, mais la transparence devient une demande contractuelle à laquelle il faudra répondre.
SBOM, les bénéfices concrets pour une organisation
Au-delà de la conformité, plusieurs gains justifient l'effort
- La réponse aux incidents s'accélère nettement. Repérer les vulnérabilités affectant vos produits passe de plusieurs jours à quelques minutes, ce qui change la gestion des risques en situation d'urgence.
- La négociation commerciale se simplifie. Un prestataire capable de fournir un SBOM propre inspire confiance et raccourcit les audits de sécurité de ses clients.
- La dette technique devient visible. Un SBOM complet révèle les bibliothèques et dépendances obsolètes que personne n'ose toucher, et permet de planifier leur remplacement.
- La conformité se vérifie en amont, ce qui évite les mauvaises surprises juridiques après la mise sur le marché.
- Le dialogue entre les intervenants s'améliore. Développement, sécurité et juridique partagent enfin une même référence, avec des données claires plutôt que des estimations.
SBOM, le cas difficile des produits embarqués
Tout ce qui précède suppose un développement logiciel moderne, avec un gestionnaire de paquets, une chaîne d'intégration continue et des équipes qui maîtrisent leur code source avec exigence. Dans les produits embarqués, ces conditions sont rarement réunies.
Pourquoi c'est plus compliqué
Un équipement industriel, une borne, un calculateur ou un terminal reste en service dix à quinze ans. Le logiciel qu'il contient a souvent été écrit par une équipe qui n'existe plus, avec des outils dont le support a cessé.
Les dépendances y sont fréquemment intégrées en dur, copiées directement plutôt que déclarées dans un document de configuration.
Aucun gestionnaire de paquets ne peut alors reconstituer la liste.
Le firmware compilé ne dit pas facilement ce qu'il contient. Identifier une bibliothèque figée dans un binaire embarqué exige une analyse spécifique, pas un simple scan.
Les contraintes matérielles compliquent la mise à jour. Corriger une vulnérabilité suppose parfois d'intervenir physiquement sur un parc réparti, ce qui change complètement l'équation du risque.
Ce que ça implique concrètement
Pour un fabricant de produits embarqués, produire un SBOM conforme aux exigences du Cyber Resilience Act suppose souvent un travail préalable de reprise. Il faut analyser le code existant, reconstituer l'inventaire des composants utilisés, évaluer leur exposition, puis mettre en place une chaîne de génération pour les versions futures.
C'est un travail de fond, pas une case à cocher. Et il requiert de savoir intervenir sur du logiciel embarqué ancien, ce qui est un métier en soi.
C'est précisément l'activité d'Elipce en tant qu'éditeur de logiciel embarqué, qui couvre la conception, le développement et la maintenance de logiciels intégrés dans des équipements industriels et de terrain, y compris la reprise de bases de code dont l'historique s'est perdu.
Questions fréquentes
- La traduction française de Software Bill of Materials.
- C'est un document structuré qui répertorie tous les composants logiciels présents dans une application, avec leurs versions et leurs licences.
- SPDX, normalisé par l'ISO, est orienté conformité et gestion des licences.
- CycloneDX, issu de l'OWASP, est orienté sécurité applicative et analyse des vulnérabilités.
- Les deux formats sont largement supportés et convertibles.
- Il l'est pour les fournisseurs du gouvernement fédéral américain, et le Cyber Resilience Act le rend nécessaire en Europe pour les produits comportant des éléments numériques.
- De plus en plus de clients l'exigent contractuellement, indépendamment de toute réglementation.
- Avec un outil intégré à votre chaîne de build, qui analyse les dépendances ou le binaire produit.
- Syft, associé à Grype pour l'analyse de vulnérabilités, constitue une combinaison éprouvée.
- L'essentiel est d'automatiser la génération à chaque livraison.
- L'analyse de composition logicielle, ou SCA, est le processus qui identifie les composants et évalue les risques.
- Le SBOM est le document produit et partagé.
- L'un est une activité, l'autre un livrable.
- Non. Il offre la visibilité indispensable, mais la sécurité logicielle dépend du processus qui exploite cette information, de la détection à la correction effective.
Le SBOM n'est pas une formalité administrative.
C'est l'outil qui permet de répondre à une question simple que peu d'organisations savent traiter aujourd'hui, à savoir ce "que contient réellement le logiciel livré aux clients."
Si vos logiciels embarquent des composants tiers dont vous ignorez le détail :
Contactez-nous !