Définir la question à laquelle répondre

Un SBOM, ou nomenclature des composants logiciels, décrit un ensemble de composants sur un périmètre donné. Avant de choisir un outil, précisez l’usage visé : connaître les dépendances d’une application, suivre une livraison ou préparer l’analyse d’un composant signalé.

Cette question oriente le moment de génération et le contenu attendu. Un inventaire issu d’un dépôt de code et un inventaire produit à partir d’un artefact livré ne décrivent pas nécessairement le même objet. Indiquez ce que votre procédure observe effectivement.

Relier l’inventaire à une version identifiable

Prévoyez une association explicite entre le SBOM, le projet et la version à laquelle il se rapporte. Sans ce lien, il devient difficile de retrouver l’inventaire correspondant à une livraison ou de comparer deux états.

Dans un pilote, conservez le fichier produit, la date de génération et les informations nécessaires pour répéter l’opération. Vérifiez aussi les identifiants des composants et les informations de version, en signalant les valeurs absentes ou ambiguës.

Traiter la qualité comme une étape du processus

L’import d’un fichier ne suffit pas à valider son utilité. Choisissez quelques contrôles simples : le bon projet est-il identifié ? Les composants attendus sont-ils présents ? Les versions sont-elles lisibles ? Le périmètre de génération est-il documenté ?

L’analyse de vulnérabilités constitue une étape supplémentaire qui utilise ces données. Ses résultats doivent être examinés avec les informations du projet. Un SBOM est un support d’analyse ; son existence seule ne démontre pas la sécurité d’une application.

Commencer par un projet pilote

Sélectionnez un projet dont l’équipe peut expliquer la construction et la livraison. Convenez d’un responsable de génération, d’un emplacement de collecte et d’un circuit pour traiter les résultats.

À la fin du pilote, relevez les données manquantes, les personnes capables de les compléter et les tâches à automatiser. Utilisez ce bilan pour préparer la collecte sur les autres projets.

Pour appliquer cette méthode, partez de vos versions déployées, de vos contraintes de maintenance et des informations de support de vos fournisseurs.