SBOM (Software Bill of Materials)

Un Software Bill of Materials liste tous les composants (bibliothèques, paquets système, leurs versions exactes) qui composent une image ou un artefact logiciel. C’est l’équivalent de la liste d’ingrédients d’un produit alimentaire : pas une garantie de qualité en soi, mais la donnée sans laquelle aucune question de traçabilité ne peut recevoir de réponse rapide.

Pourquoi le générer au build

Un scanner de vulnérabilités calcule déjà cet inventaire à chaque scan, mais le jette après usage. Le conserver comme artefact change ce qu’on peut faire ensuite : quand une nouvelle CVE est publiée contre une bibliothèque, vérifier l’exposition sur toutes les images déjà livrées devient une requête sur des SBOM archivés, pas un rescan de chaque artefact historique, certains n’étant parfois plus reconstructibles à l’identique des mois plus tard.

Un format, pas un scanner

Un SBOM (souvent au format SPDX ou CycloneDX) est produit par des outils comme syft, indépendamment du scanner de vulnérabilités utilisé pour l’interroger. Les deux se complètent : l’un dit ce qu’il y a dedans, l’autre dit si c’est vulnérable, et cette réponse change dans le temps même quand l’image, elle, ne change plus.