Établir le logiciel de facturation des matériaux, ou "SBOM" — aux côtés du logiciel lui-même — est une bonne pratique pour surveiller les vulnérabilités de jour zéro ou répondre aux besoins réglementaires et de conformité.

‍Le SBOM est également prêt pour les exigences de transparence logicielle émergentes dans des domaines bien réglementés tels que les finances, les soins de santé et les agences fédérales.

‍Des outils commerciaux et open-source existent pour construire des SBOM pour des projets logiciels dans la plupart des écosystèmes logiciels et à partir de binaires d'application et de firmware.

‍Cependant, un produit logiciel typiquement disponible dans le commerce ou un appareil connecté est construit comme une collection de logiciels et de matériel projets assemblés à partir de plusieurs composants matériels, bibliothèques, services, ou même la distribution directe d'exécutables.

‍

Pour des exemples :

• Une application mobile inclut des bibliothèques tierces pour des besoins de marketing, d'authentification ou de publicité — toutes provenant de fournisseurs tiers.

• Un dispositif médical peut inclure des composants programmables de divers fournisseurs, chacun avec ses propres versions et cycles de mise à niveau.

• Une application de bureau peut avec certains exécutables tiers qu'elle appelle pour des fonctionnalités spécifiques.

Dans ces cas, le SBOM pour des projets et bibliothèques peut être construit avec le projet mais la combinaison de ceux-ci dans le produit SBOM final nécessite une compréhension plus profonde des formats et des limitations du SBOM.

Construire un produit SBOM final en combinant le projet SBOM résout plusieurs problèmes, y compris :

• Fournir un seul produit SBOM au lieu de nombreux projet SBOM

• Suivre la version du produit par rapport aux versions spécifiques des projets

• Suivre le produit final avec un seul SKU dans les systèmes de gestion SBOM

• Mapper les vulnérabilités nouvellement divulguées à des projets spécifiques