Qu’est-ce qu’un SBOM, le Software Bill of Materials ?
Publié sur LinkedIn le 28 aout 2026
Lorsqu’une vulnérabilité critique est publiée, la première question devrait être simple :
« Sommes-nous concernés ? »
Pourtant, dans beaucoup d’organisations, la réponse prend des heures, parfois des jours.
Pourquoi ?
Parce que personne ne sait quels composants, bibliothèques, versions et dépendances sont intégrés dans les logiciels utilisés ou commercialisés.
C’est le rôle du SBOM.
Un Software Bill of Materials est une nomenclature logicielle : un inventaire structuré des composants qui constituent un logiciel.
On peut le comparer à la liste des ingrédients d’un produit alimentaire.
Il peut contenir le nom des composants, leurs versions, leurs fournisseurs, les relations de dépendance, les licences et la version du produit concerné.
Lorsqu’une faille touche une bibliothèque largement utilisée, le SBOM doit permettre d’identifier les applications et produits concernés.
Sans SBOM, chaque vulnérabilité devient une enquête.
Il faut fouiller les dépôts, analyser les paquets, interroger les fournisseurs et parfois découvrir une dépendance indirecte inconnue.
Avec un SBOM fiable, la qualification s’accélère :
sommes-nous exposés ?
sur quelles versions ?
dans quels produits ?
chez quels clients ?
quelle correction faut-il prioriser ?
Mais produire un fichier ne suffit pas.
Un SBOM doit être complet, lisible par les outils, associé à une version précise, mis à jour à chaque livraison et intégré à la gestion des vulnérabilités.
Le SBOM ne garantit pas qu’un composant est sécurisé.
Il ne remplace ni l’analyse de risque, ni les tests, ni les correctifs, ni la surveillance des dépendances.
Il apporte quelque chose de fondamental : la visibilité.
Et cette visibilité devient stratégique avec le Cyber Resilience Act.
Le CRA impose aux fabricants de mieux maîtriser la cybersécurité de leurs produits numériques pendant tout leur cycle de vie.
Difficile de corriger les vulnérabilités d’un produit lorsque l’on ignore ce qu’il contient.
Pour les entreprises, le chantier est concret :
automatiser la génération des SBOM ;
les intégrer aux chaînes CI/CD ;
les relier aux bases de vulnérabilités ;
encadrer leur transmission ;
exiger des SBOM auprès des fournisseurs ;
définir qui les tient à jour et qui les exploite.
La vraie question n’est pas :
« Avons-nous un SBOM ? »
Mais :
« Pouvons-nous l’utiliser pour identifier en quelques minutes tous les produits touchés par une vulnérabilité critique ? »
Une simple liste est un livrable.
Un SBOM fiable devient une capacité de décision, de correction et de résilience logicielle.
PS : Si vous découvrez mon contenu (veille CERT, Post), je vous invite à me suivre ici sur LinkedIn
#SBOM #SoftwareBillOfMaterials #Cybersécurité #CRA #SécuritéLogicielle #GestionDesVulnérabilités #DevSecOps #RésilienceIT
