SBOM : informations sur les composants, formats et maintenance
Sytance · Mis à jour
Une nomenclature logicielle (SBOM) décrit les composants logiciels d’une application ou d’un système ainsi que leurs relations. Elle constitue un point de départ pour l’inventaire des composants, l’examen des licences et l’investigation des vulnérabilités. Son utilité dépend de la fidélité avec laquelle elle décrit le logiciel réellement livré.
Le produit décrit par une SBOM
Une SBOM décrit une version de produit, un build ou un artefact précis, par exemple une image de micrologiciel ou un paquet d’installation. Les entrées identifient les bibliothèques et autres logiciels compris dans ce périmètre. Les versions, producteurs, identifiants et relations indiquent ce qui a été inclus.
Pour une passerelle industrielle fictive, la version du micrologiciel est le produit cible. Son application de gestion et ses bibliothèques intégrées sont des composants. Un service de télémétrie à distance est une dépendance externe ; le décrire ne signifie pas que ses paquets côté serveur sont inclus dans le micrologiciel.
L’exemple public utilise des composants fictifs pour rendre la structure lisible. Il ne s’agit pas d’un inventaire de composants de Sytance ou d’une passerelle commercialisée.
Identifiants des composants
Deux paquets dont les noms se ressemblent peuvent appartenir à des écosystèmes de paquets différents. Une Package URL (purl) identifie un paquet au moyen de champs tels que le type, l’espace de noms, le nom et la version. Le hachage d’un fichier permet d’identifier un fichier précis lorsque l’algorithme de hachage et le fichier haché sont connus.
Utilisez les métadonnées du paquet ou les informations du fournisseur pour établir les identifiants. Une purl construite à partir d’un fournisseur supposé peut désigner le mauvais paquet. Conservez la chaîne de version d’origine, car un build en aval peut inclure sa propre révision de correctif.
SPDX et CycloneDX représentent tous deux des informations sur les composants logiciels et leurs relations. Les champs disponibles et leur signification exacte dépendent de la version du format. Choisissez une version que les outils de production et de réception peuvent traiter.
Exactitude et couverture de l’inventaire
Un fichier peut être un JSON valide tout en décrivant la mauvaise version. Comparez la SBOM aux entrées de build et à l’artefact livré, puis examinez les écarts. Une liste de dépendances du code source peut contenir des outils de développement qui n’ont jamais été livrés et omettre des bibliothèques copiées dans l’image.
- Cible : le produit, la version et l’artefact correspondent à la livraison.
- Identité : les versions et identifiants des composants peuvent être reliés à des preuves.
- Relations : les chemins de dépendance sont présents et pertinents.
- Couverture : les données manquantes des fournisseurs et les parties non analysées sont visibles.
- Échange : l’outil destinataire conserve les champs nécessaires à l’utilisation prévue.
Éléments minimaux SBOM 2026
Les éléments minimaux SBOM 2026, publiés conjointement par la CISA et ses agences partenaires, actualisent les recommandations de la NTIA de 2021. Ils portent sur les métadonnées des documents, les données des composants et les pratiques de maintenance et de partage des SBOM. Cette publication fournit des recommandations et précise qu’elle ne crée pas de nouvelles exigences.
Pour une livraison, indiquez la spécification convenue, la version du format et les exigences supplémentaires du client. La réussite de la validation du schéma ne suffit pas à établir que les informations demandées par le client sont complètes.
Correspondances de vulnérabilités et impact sur le produit
Une correspondance de vulnérabilité relie un problème signalé à l’identité ou à la version d’un composant. Il faut ensuite déterminer si le code affecté existe dans ce produit et s’il peut être exploité. Vérifiez les options de build, les modifications, les chemins d’exécution et les conditions décrites dans l’avis.
Vulnerability Exploitability eXchange (VEX) communique l’évaluation d’une vulnérabilité donnée pour des produits identifiés. Reliez cette évaluation à la version livrée et à l’analyse qui l’étaye. L’absence de correspondance peut refléter une couverture limitée ou des identifiants incomplets.
Dossiers des versions prises en charge
Archivez l’inventaire d’origine avec la version publiée. Si de nouvelles informations corrigent la SBOM sans modifier le logiciel, publiez une révision documentaire traçable. Si le logiciel change, créez un dossier pour la nouvelle version.
Lorsqu’un nouvel avis signale une vulnérabilité dans un composant, recherchez-la dans les inventaires de toutes les versions prises en charge. Les clients peuvent encore utiliser une ancienne version dont les composants diffèrent de ceux du produit actuel.