Qu'est-ce qu'un SBOM
La définition
Un SBOM (software bill of materials, nomenclature logicielle) est un inventaire structuré, formel et lisible par machine des composants logiciels contenus dans un produit et de leurs relations.
L’analogie de l’étiquette des ingrédients est utile pour poser l’idée, et trompeuse au-delà : une étiquette est statique et se lit à l’œil, un SBOM change à chaque construction et n’a de valeur que traité par une machine.
Les données attendues par composant
| Donnée | Pourquoi elle compte |
|---|---|
| Nom | Identification humaine |
| Version | Sans version, aucune corrélation avec une vulnérabilité n’est possible |
| Fournisseur ou éditeur | Distingue deux composants homonymes |
| Identifiant unique — PURL, CPE | Permet la corrélation automatique |
| Empreintes cryptographiques | Lie l’inventaire à l’artefact réel |
| Licence en identifiant SPDX | Conformité juridique et propriété intellectuelle |
| Relations de dépendance | Distingue direct et transitif, permet de remonter le chemin d’introduction |
| Auteur de l’inventaire et horodatage | Traçabilité, opposabilité |
Un inventaire sans version ni identifiant résolvable n’est pas un SBOM exploitable : c’est une liste de noms.
Les usages, par public
| Public | Ce que le SBOM permet |
|---|---|
| Juridique | Constituer le dossier technique, démontrer la conformité aux licences, répondre aux questionnaires clients et aux diligences d’investisseurs |
| Cyber / PSIRT | Répondre en minutes à « êtes-vous affectés ? », prioriser, produire des VEX, alimenter le signalement |
| Achats | Instruire la diligence fournisseur, comparer des offres sur une base factuelle |
| Produit | Suivre l’obsolescence, anticiper les fins de support des composants, arbitrer la dette technique |
| Direction | Mesurer l’exposition du portefeuille, suivre les indicateurs de couverture |
Ce que le SBOM n’est pas
- Pas un rapport de vulnérabilités. C’est la donnée d’entrée qui permet d’en produire un, en confrontant l’inventaire à des bases qui évoluent chaque jour.
- Pas un audit de licences. C’est la donnée qui permet d’en faire un.
- Pas une preuve d’absence de code malveillant. Un composant peut être correctement inventorié et compromis. Le SBOM répond à « qu’y a-t-il dedans », pas à « est-ce sain ».
- Pas un document figé. Un SBOM est attaché à une construction précise. Un SBOM « du produit », sans version, n’a pas de sens.
Le test de réalité
Une organisation sait où elle en est avec une seule question : combien de temps vous a-t-il fallu, la dernière fois, pour répondre à « êtes-vous affectés par cette vulnérabilité, et dans quelles versions livrées ? »
- Plusieurs semaines, par courriels et tableurs : vous n’avez pas de SBOM exploitable.
- Quelques jours, en interrogeant chaque équipe : vous générez des SBOM mais vous ne les centralisez pas.
- Quelques minutes, par une requête : le dispositif décrit dans Générer et piloter est en place.