Elle peut identifier les composants propriétaires et tiers, les versions, les fournisseurs, les identifiants uniques, les relations de dépendance et des informations sur quand et comment l'enregistrement a été créé.
Un SBOM donne aux producteurs et aux consommateurs un inventaire partagé pour des questions telles que la présence d'un composant, les produits potentiellement affectés par une information nouvelle et les endroits où une revue de licence ou de maintenance est nécessaire. Des standards lisibles par machine comme SPDX et CycloneDX facilitent l'échange et l'automatisation de ces informations. Le SBOM doit néanmoins être lié à une publication ou un artefact précis et tenu à jour à mesure que le logiciel change.
Points clés
Informations essentiellesAuteur du SBOM, producteur du logiciel, noms et versions des composants, identifiants et hachages, licences, relations de dépendance, outil et contexte de génération, horodatage et couverture déclarée.
Usages opérationnelsDécouverte de composants, investigation de vulnérabilités, revue de licences, communication avec les fournisseurs, corrélation d'actifs et comparaison entre versions du logiciel.
Contrôles de qualitéGénérer près du build faisant autorité, inclure les composants transitifs et embarqués, énoncer les limites d'exhaustivité connues, valider les identifiants, protéger l'intégrité et définir des règles de partage.
Limite importanteUn SBOM est un inventaire, pas un verdict de vulnérabilité ou d'exploitabilité. Il peut montrer qu'un composant est présent sans montrer si le code affecté est joignable, configuré ou mitigé.