À l'origine des SBOM se trouvent les risques liés aux dépendances logicielles.
De par leur imbrication, il est difficile pour un développeur de connaître exhaustivement toutes celles que son projet incorpore.
En face de lui, les pirates ont tout intérêt à rechercher des dépendances vulnérables dans les cibles qu'ils attaquent, notamment grâce aux techniques de fingerprint.

Pour remédier à cet angle mort très dangereux, de plus en plus de référentiels de cybersécurité exigent que les éditeurs produisent des Software Bill of Materials (SBOM) de leur produit.
Ça consiste à lister les dépendances de son logiciel, puis les dépendances des dépendances, etc. Donc à cartographier tout ce dont notre produit dépend.
C'est un peu comme une liste d'ingrédients pour un médicament ou un aliment. Et ça sert la même finalité : si un ingrédient est découvert comme étant toxique, on peut savoir s'il y a un risque à consommer tel médicament ou tel aliment selon qu'il le contienne ou non.

Ça se présente sous la forme d'un fichier qui respecte une certaine nomenclature de sorte que son traitement puisse être automatisé.
Mais il y a des limites à la profondeur à laquelle on peut aller, notamment si on incorpore des outils qui ne sont pas open source (et dont on ignore les dépendances car c'est une boite noire).