Qu'est-ce qu'une SBOM ?

Que signifie SBOM ?

SBOM signifie software bill of materials, c'est-à-dire nomenclature logicielle. Le terme vient de l'industrie, où une nomenclature liste les pièces qui entrent dans un produit. La CISA décrit une SBOM comme un inventaire imbriqué, une liste des ingrédients qui composent les composants logiciels.

L'essentiel du code d'une application moderne a été écrit par d'autres, et l'essentiel de ce code arrive indirectement : vous ajoutez un paquet, et il apporte des dizaines de dépendances transitives. Une SBOM consigne le tout, pour que vous puissiez répondre à la question « sommes-nous touchés ? » sans lire un seul dépôt.

Que contient une SBOM ?

Une SBOM utile comporte deux parties : des données sur la SBOM elle-même, et des données sur chaque composant. Les 2026 Minimum Elements, publiés par la CISA, la NSA et le FBI avec des partenaires internationaux le 29 juillet 2026, remplacent la liste NTIA de 2021 et fixent la base de référence à laquelle la plupart des acheteurs se réfèrent désormais.

Partie	Champs
Sur la SBOM	Auteur et signature de l'auteur, horodatage, nom et version du format de données, nom et version de l'outil, version de la SBOM et contexte de génération
Sur chaque composant	Nom, version, producteur, identifiants tels qu'une package URL, valeur de hachage et algorithme, licence et relations de dépendance

Le contexte de génération compte plus qu'il n'y paraît. Il indique quand la SBOM a été produite : avant le build, pendant le build, à partir de l'artefact final ou après. Deux SBOM d'une même release peuvent différer précisément pour cette raison. Consultez les exemples de SBOM pour voir à quoi ressemblent ces champs dans un vrai fichier.

Formats de SBOM

Deux formats couvrent la quasi-totalité des SBOM utilisées. CycloneDX, de l'OWASP, vient du monde de la sécurité et décrit aussi les vulnérabilités et les services. SPDX, de la Linux Foundation, vient de la conformité des licences. Les deux peuvent contenir les éléments minimaux, et la plupart des outils écrivent les deux. Consultez CycloneDX vs SPDX pour savoir comment choisir.

Pourquoi les SBOM sont importantes

• Une réponse aux incidents plus rapide. Quand une vulnérabilité comme Log4Shell surgit, la question est de savoir lesquels de vos produits la contiennent. Avec des SBOM, c'est une recherche. Sans elles, c'est un projet.
• Le suivi des vulnérabilités après la release. Un logiciel sain à sa livraison peut être vulnérable demain. Revérifier les SBOM stockées par rapport aux nouveaux avis de sécurité permet de le détecter sans rien reconstruire.
• Le risque de licence. La licence déclarée de chaque composant fait apparaître les conditions copyleft ou commerciales avant qu'elles n'atteignent le produit.
• Les questions des clients et des régulateurs. Les acheteurs demandent de plus en plus une SBOM lors des achats, et plusieurs cadres attendent un inventaire des composants.

Qui a besoin d'une SBOM ?

Quiconque livre un logiciel, et quiconque doit répondre de ce qu'il contient. L'exigence arrive généralement par l'une de ces voies :

• Dispositifs médicaux. La section 524B de la FDA exige une SBOM pour les « cyber devices » dans les dossiers de pré-commercialisation.
• Produits vendus dans l'UE. Le Cyber Resilience Act demande une SBOM aux fabricants. Consultez les exigences SBOM du CRA et les outils.
• Marchés publics fédéraux américains. Le mémo OMB M-26-05 de janvier 2026 laisse chaque agence décider de l'exiger ou non : attendez-vous donc à un traitement au cas par cas.
• Logiciels de paiement. L'exigence 6.3.2 de PCI DSS 4.0 demande un inventaire des logiciels sur mesure et de leurs composants tiers. Elle ne prescrit pas de SBOM, mais une SBOM répond au besoin.

Comment générer une SBOM

Il existe trois façons d'en produire une, et la méthode détermine ce qui se retrouve dans le fichier.

Méthode	Ce qu'elle lit	Lacune typique
Scanner la source	Les manifestes et lockfiles du dépôt	Tout ce que le build récupère et qu'aucun lockfile ne liste
Scanner le résultat	Une image de conteneur ou un binaire terminé	Le code compilé est ambigu, et les outils de build ne laissent aucune trace
Enregistrer le build	Ce que le build a réellement récupéré pendant son exécution	Le trafic qui contourne l'enregistreur, qui doit être signalé

Les générateurs open source tels que Syft, Trivy et cdxgen utilisent les deux premières méthodes. Ils se contredisent sur un même commit, car chacun a ses propres règles sur ce qu'il faut lire. Pour comparer les options, consultez les meilleurs outils SBOM.

SBOM vs SCA vs VEX

• Une SBOM est un inventaire. Elle dit ce qui s'y trouve, pas si c'est sûr.
• L'analyse de la composition logicielle (SCA) est l'analyse. Elle repère les composants et en vérifie les risques, et de nombreux outils SCA produisent une SBOM au passage.
• VEX est une déclaration d'impact. Elle indique si une vulnérabilité connue touche réellement votre produit, ce qui réduit le bruit qu'une SBOM génère à elle seule.

Générer une SBOM est la partie facile

Un fichier que personne ne lit ne change rien. La valeur vient du fait de conserver une SBOM par release, de les surveiller et de pouvoir les retrouver quand cela compte. Ce travail, c'est la gestion des SBOM, et les bonnes pratiques SBOM expliquent comment la mener.

Comment CRACI crée les SBOM

CRACI est un runner GitHub Actions qui enregistre chaque paquet récupéré par chaque job, à tous les niveaux de l'arbre, y compris les paquets restaurés depuis les caches CI. Le résultat est une SBOM du build qui a produit la release, avec un état de complétude qui indique ce que le job n'a pas pu voir. Elle s'exporte en CycloneDX ou SPDX, et CRACI continue de la réévaluer à mesure que de nouvelles vulnérabilités sont publiées. Consultez la génération de SBOM au build.

SBOM : questions fréquentes

Qu'est-ce qu'une SBOM, en termes simples ?

Une SBOM est une liste d'ingrédients pour logiciel. Elle nomme chaque composant d'un produit, avec sa version, son producteur et sa licence, dans un format lisible par machine.

Que signifie SBOM ?

SBOM signifie software bill of materials, c'est-à-dire nomenclature logicielle.

Pourquoi avoir besoin d'une SBOM ?

Pour savoir rapidement si une vulnérabilité nouvellement publiée touche ce que vous livrez, voir le risque de licence avant la release et répondre aux clients et aux régulateurs qui demandent ce que contient votre produit.

Quels sont les deux principaux formats de SBOM ?

CycloneDX et SPDX. CycloneDX vient de l'OWASP et du monde de la sécurité. SPDX vient de la Linux Foundation et de la conformité des licences. Les deux peuvent contenir les éléments minimaux.

La SBOM est-elle obligatoire légalement ?

Cela dépend du produit et du marché. La section 524B de la FDA en exige une pour les « cyber devices », et le Cyber Resilience Act de l'UE en demande une aux fabricants. Dans les marchés publics fédéraux américains, la décision revient désormais à chaque agence. Pour beaucoup d'autres entreprises, c'est une exigence des clients plutôt qu'une exigence légale.

À quelle fréquence faut-il mettre à jour une SBOM ?

Générez une nouvelle SBOM à chaque release, car chaque build peut récupérer des versions différentes. La SBOM d'une release ne change plus ensuite, mais vous devez continuer à la vérifier par rapport aux nouvelles vulnérabilités.

Qui crée la SBOM ?

Généralement l'équipe qui construit le logiciel, idéalement dans la CI, pour que chaque release en obtienne une automatiquement. Les logiciels que vous achetez devraient être accompagnés d'une SBOM de leur fournisseur.