La dernière construction ne représente pas tout le parc
La nouvelle version a passé les contrôles du pipeline, mais la précédente reste utilisée chez plusieurs clients. Une vulnérabilité publiée demain peut concerner cette ancienne livraison. Si vous remplacez son inventaire par celui de la dernière construction, elle disparaît du suivi alors qu’elle reste déployée.
Reliez chaque SBOM au produit, à sa version et à l’artefact décrit, puis aux installations connues. Conservez la provenance et la date de collecte. Pour arrêter le suivi d’une version, il faut savoir qui peut confirmer son retrait : le succès de la nouvelle livraison ne renseigne pas l’état de toutes les anciennes installations.
Séparer inventaire, connaissance des défauts et traitement
CycloneDX décrit la SBOM comme un inventaire de composants et de services avec leurs relations. SPDX fournit aussi un vocabulaire commun pour les informations logicielles. Leur exploitation dépend de la collecte : versions absentes, dépendances oubliées et provenances ambiguës limitent les rapprochements, même lorsque le fichier respecte son schéma.
Distinguez trois événements : une nouvelle SBOM décrit un logiciel ou une collecte modifiés ; une actualisation des sources peut révéler des vulnérabilités sur l’inventaire existant ; une preuve de correction confirme le traitement d’une installation. Un nouveau dossier peut donc apparaître sans changement de logiciel. Et une SBOM récemment importée ne suffit pas à prouver qu’une mise à jour a été déployée.
Sources : CycloneDX, capacités SBOM, SPDX, profil Software
Garder des identifiants et des versions interprétables
Distinguez le produit commercial du composant, puis précisez l’écosystème, la version et la provenance. CPE et PURL facilitent les échanges, mais l’identifiant seul ne confirme pas l’applicabilité. OSV distingue les écosystèmes et leurs règles de versions : deux paquets homonymes peuvent désigner des composants différents.
Quand une donnée manque, adressez une demande précise au fournisseur : version embarquée, dépendance transitive, variante ou construction. Gardez le dossier en attente du complément. Cette traçabilité permet de réutiliser ensuite la qualification sur les autres installations qui partagent les mêmes conditions.
Sources : OpenSSF, schéma OSV 1.9.2
Organiser la continuité avec ou sans pipeline
Avec une intégration CI/CD, associez la SBOM à la construction avant de la transmettre au suivi. Définissez une convention stable pour le produit, la version et l’artefact. Distinguez les versions en développement, celles publiées et celles encore utilisées : leur statut de maintenance et leurs destinataires peuvent différer.
Sans connexion au pipeline, organisez la collecte des exports ou SBOM avec les équipes et fournisseurs. Précisez qui les transmet, quand les renouveler et comment réanalyser les inventaires conservés. L’absence de pipeline n’empêche pas l’actualisation des sources sur Internet. Un environnement déconnecté pose une autre question : celle des transferts autorisés et de leur fréquence.
Exemple fictif : une ancienne version sur deux systèmes
Rivage 1.8 reste installé sur A et B pendant la préparation de 2.0. Une nouvelle information, DEMO-SBOM-01, concerne une dépendance présente dans la SBOM de 1.8. L’import de la SBOM 2.0 laisse les deux déploiements précédents dans le périmètre.
La qualification est commune si les conditions techniques concordent, mais chaque système conserve son responsable et sa preuve de traitement. A migre en premier ; B reste suivi. Sa clôture attend la confirmation du traitement ou de son retrait. L’absence d’une nouvelle collecte sur B ne vaut pas désinstallation.
Entretenir le portefeuille et mesurer la couverture
Dependency-Track permet de suivre les composants d’un portefeuille et d’organiser les projets et leurs versions. Vérifiez les fonctions actives sur votre installation : sources actualisées, versions encore analysées et regroupements utilisés pour les indicateurs. Vos conventions de gestion doivent permettre de retrouver les versions maintenues, y compris les plus anciennes.
CyberLifeCycle prend en charge la veille sur ce portefeuille à partir des inventaires reçus, puis qualifie les vulnérabilités et organise les demandes de compléments. Les alertes et les indicateurs rendent visibles les versions concernées, l’ancienneté des collectes et les dossiers en attente. Les équipes disposent des éléments nécessaires pour préparer leurs décisions de maintenance.
Sources : Dependency-Track v4.14, suivi des composants du portefeuille, Dependency-Track v4.14, organisation des projets et versions, Dependency-Track v4.14, tâches récurrentes
Sources consultées
- CycloneDX, capacités SBOMConsulté le 30 octobre 2026.
- SPDX, profil SoftwareConsulté le 30 octobre 2026.
- OpenSSF, schéma OSV 1.9.2Consulté le 30 octobre 2026.
- Dependency-Track v4.14, suivi des composants du portefeuilleConsulté le 30 octobre 2026.
- Dependency-Track v4.14, organisation des projets et versionsConsulté le 30 octobre 2026.
- Dependency-Track v4.14, tâches récurrentesConsulté le 30 octobre 2026.