Automatisation de la nomenclature logicielle

Un programme SBOM qui collecte des documents sans automatiser leur importation, leur analyse et leur exploitation est un programme de collecte de preuves, et non un programme de visibilité sur la chaîne d'approvisionnement. La valeur d'un SBOM se concrétise au moment où une nouvelle CVE est publiée pour un composant de l'inventaire, lorsque le SBOM permet à l'entreprise d'identifier immédiatement le logiciel de quel fournisseur est touché, quelle version de ce logiciel elle utilise et quelle action est requise. Cette valeur ne peut se concrétiser que si les données du SBOM sont dans un format lisible par machine, ont été importées dans un système interrogeable au regard des données de vulnérabilité actuelles et ont été mises à jour depuis la publication de la version du logiciel effectivement utilisée par l'entreprise.

La prolifération des formats est le premier obstacle à l'automatisation. Les SBOM sont produits dans plusieurs formats : SPDX (avec plusieurs sérialisations : JSON, RDF, YAML, tag-value), CycloneDX (en JSON et en XML) et divers formats propriétaires. Un programme qui accepte des SBOM dans n'importe quel format fourni par le fournisseur accumulera un ensemble de documents nécessitant des outils d'analyse différents, ce qui crée un problème de gestion d'inventaire que la plupart des processus manuels ne peuvent pas soutenir. Normaliser sur un format SBOM unique (CycloneDX JSON est le plus largement adopté pour le traitement automatisé) et exiger des fournisseurs qu'ils fournissent leurs SBOM dans ce format est le fondement de l'automatisation.

L'exigence de mise à jour continue est la deuxième dimension de l'automatisation. Les vulnérabilités logicielles sont publiées en continu : la National Vulnerability Database publie chaque semaine des centaines de nouvelles CVE. Un SBOM exact au moment de sa collecte devient progressivement obsolète comme référence de vulnérabilités, car il ne reflète pas les nouvelles CVE publiées depuis pour les composants de l'inventaire. Les plateformes de gestion automatisée des SBOM, qui surveillent en continu les inventaires de composants au regard des bases de données CVE et réinterrogent le statut de vulnérabilité de tous les composants à chaque publication de nouvelles CVE, offrent une visibilité continue sur la chaîne d'approvisionnement que l'examen manuel périodique ne peut pas offrir.

Pourquoi c’est important

L'automatisation des SBOM est importante pour la TPRM, car la valeur de renseignement d'un programme SBOM est proportionnelle à la rapidité avec laquelle les nouvelles CVE de l'inventaire suscitent la prise de conscience et l'action de l'entreprise. Un programme qui examine les SBOM une fois par an lors de la réévaluation offre une connaissance des CVE avec douze mois de retard. Un programme automatisé qui surveille en continu l'inventaire au regard des bases de données CVE offre cette connaissance dans les heures qui suivent la publication d'une CVE.

SBOM collectés comme des documents, et non analysés dans un inventaire interrogeable
Diversité des formats empêchant l'analyse automatisée
Aucune surveillance continue des CVE au regard des inventaires SBOM collectés
Ancienneté et actualité des versions des SBOM non suivies
Collecte de SBOM traitée comme une activité de conformité et non comme du renseignement sur la chaîne d'approvisionnement

À quoi ressemblent les bonnes pratiques

Les programmes matures d'automatisation des SBOM normalisent sur le format CycloneDX JSON, importent les SBOM dans une plateforme comme Dependency-Track qui surveille en continu les inventaires de composants au regard des bases de données CVE, suivent l'actualité des versions des SBOM et génèrent des alertes automatisées lorsque de nouvelles CVE touchent des composants de tout SBOM importé.

Exigence d'un format SBOM normalisé : CycloneDX JSON pour tous les fournisseurs
Importation automatisée des SBOM dans Dependency-Track ou une plateforme équivalente
Surveillance continue des CVE pour tous les inventaires de composants importés
Suivi de l'actualité des versions des SBOM : alerte lorsque l'ancienneté d'un SBOM dépasse le seuil
Alertes CVE automatisées aux responsables de la relation fournisseur lorsque des CVE touchent leur inventaire

Outils

Gestion des SBOM : Dependency-Track pour l'importation automatisée des SBOM et la surveillance continue des CVE

Dependency-Track est une plateforme open source de gestion des SBOM qui importe les SBOM CycloneDX et SPDX et surveille en continu leurs inventaires de composants au regard de bases de données de vulnérabilités, notamment NVD, OSV et GitHub Advisories. Lorsqu'une nouvelle CVE est publiée, Dependency-Track interroge automatiquement tous les SBOM importés et identifie les composants touchés. Pour les programmes de TPRM, Dependency-Track fournit la couche de surveillance continue qui transforme une collection statique de documents en un système dynamique de renseignement sur la chaîne d'approvisionnement.

Génération de SBOM : Syft, cdxgen pour la génération automatisée de SBOM ; cyclonedx-cli pour la conversion de formats

Pour les fournisseurs qui fournissent leurs SBOM dans des formats non standard, des outils de conversion peuvent passer d'un format SBOM à un autre, ce qui permet l'importation dans des plateformes normalisées quel que soit le format produit par le fournisseur. cyclonedx-cli assure la conversion entre les formats SPDX et CycloneDX.

Enjeux de gouvernance

Le défi de gouvernance de l'automatisation des SBOM est l'exigence de conformité imposée aux fournisseurs. Exiger des fournisseurs qu'ils fournissent leurs SBOM au format CycloneDX JSON plutôt que dans un format qui les arrange transfère la charge de la normalisation aux fournisseurs plutôt qu'à l'entreprise. Certains fournisseurs s'y conformeront volontiers ; d'autres résisteront. La solution de gouvernance est une mise en œuvre par niveaux : exiger immédiatement des SBOM lisibles par machine des fournisseurs de niveau critique, puis étendre aux autres niveaux à mesure que la conformité des fournisseurs progresse.

Exiger le format CycloneDX JSON des fournisseurs de niveau critique
Mettre en place Dependency-Track ou un équivalent pour la gestion automatisée des SBOM
Configurer une surveillance continue des CVE pour tous les SBOM importés
Suivre l'actualité des versions des SBOM et demander des mises à jour lorsque les SBOM dépassent l'ancienneté seuil
Automatiser l'acheminement des alertes CVE vers les responsables de la relation fournisseur

Si vous êtes une petite équipe

Déployez Dependency-Track : c'est gratuit, open source, et il peut fonctionner dans votre environnement en une journée. Prenez ensuite les dix SBOM les plus récents reçus de fournisseurs critiques et redemandez-les au format CycloneDX JSON s'ils ne sont pas déjà dans ce format. Importez-les tous les dix dans Dependency-Track et configurez la surveillance des CVE. En 24 heures, vous disposerez pour ces dix fournisseurs d'un inventaire de chaîne d'approvisionnement surveillé en continu, qui offre plus de visibilité sur la chaîne d'approvisionnement que des années de collecte de documents n'auraient pu en produire.

Déployer Dependency-Track pour la gestion des SBOM
Redemander aux fournisseurs critiques leurs SBOM au format CycloneDX JSON
Importer dans Dependency-Track et configurer une surveillance continue des CVE
Automatiser l'acheminement des alertes CVE vers les responsables de la relation fournisseur

Ce qu’il faut exiger

Demandez directement :

« Pouvez-vous fournir votre SBOM au format CycloneDX JSON, propre à la version que nous utilisons, et disposez-vous d'un processus pour nous informer de manière proactive lorsqu'une nouvelle CVE est publiée pour un composant de votre logiciel ? »

Preuves attendues

SBOM au format CycloneDX JSON pour la version actuellement déployée
Processus de notification des CVE pour les vulnérabilités des composants
Cadence de mise à jour du SBOM : fréquence des mises à jour
Capacité de notification automatisée des vulnérabilités

Il faut demander à un fournisseur qui fournit un SBOM de le fournir au format CycloneDX JSON et l'interroger sur son processus de notification des CVE. CycloneDX JSON permet l'automatisation. La notification des CVE apporte le renseignement proactif qu'un examen annuel tardif ne peut pas fournir.

Comment le prouver

Déploiement de Dependency-Track ou d'un équivalent
Collecte de SBOM au format CycloneDX JSON
Registres de surveillance continue des CVE
Processus d'alerte et de réponse CVE

À retenir

847 documents SBOM. 7 formats. 93% jamais analysés. 41% datant de plus de 12 mois. Visibilité sur la chaîne d'approvisionnement : aucune. Le programme collectait des preuves de conformité. Il ne construisait pas de renseignement sur la chaîne d'approvisionnement. La valeur d'un SBOM se concrétise au moment de la publication d'une CVE, lorsque l'inventaire identifie immédiatement le logiciel de quel fournisseur est touché. Cette valeur exige un format lisible par machine, une importation automatisée, une surveillance continue des CVE et des versions à jour. Dependency-Track est gratuit et peut fonctionner le jour même. CycloneDX JSON est le format de référence. La surveillance continue est la capacité qui transforme la collecte de documents en renseignement.