Au cours des dernières années, les gens sont devenus de plus en plus conscients des risques inhérents à l’utilisation de composants open source dans leurs logiciels. Étant donné que la plupart des logiciels sont un mélange de logique open source et propriétaire, savoir quels ingrédients ont été importés de l’extérieur, directement ou temporairement, est essentiel pour une bonne gestion des risques du produit logiciel final. Étant donné que l’époque du suivi des ingrédients à l’aide de feuilles de calcul compliquées est révolue depuis longtemps et terriblement inefficace, le principal moyen d’effectuer un tel suivi consiste à utiliser un SBOM – une nomenclature logicielle. Comme les autres nomenclatures, il s'agit essentiellement d'une liste des ingrédients logiciels à partir desquels le logiciel est construit, avec l'ajout des relations entre les différents ingrédients, avec un accent particulier sur les composants qui dépendent les uns des autres.
Il existe aujourd'hui deux principaux formats SBOM utilisés sur le marché : SPDX et CycloneDX.
Échange de données de progiciels (SPDX) est un projet SBOM open source et lisible par machine de la fondation Linux. La dernière version du SPDX a été conçue conformément à la norme de la NTIA pour 'Éléments minimaux pour une nomenclature logicielle.' Il répertorie les composants, les droits d'auteur, les licences et les références de sécurité d'un logiciel.
CycloneDX (CDX) est également un format SBOM open source et lisible par machine développé par la communauté Open Web Application Security Project (OWASP). En tant que format de nomenclature, CycloneDX a d'autres applications au-delà de la préparation de nomenclatures logicielles. Il peut également être utilisé pour compiler des composants, des vulnérabilités et des services de matériel et de systèmes cloud.
Pourquoi le SBOM est-il important ?
Le SBOM est extrêmement utile aux équipes de développement de logiciels, aux organisations d'achats et aux utilisateurs finaux. Son utilisation peut contribuer à garantir que les composants open source et tiers sont à jour et offre une visibilité sur les dépendances du projet qui présentent des vulnérabilités connues qui pourraient être exploitables dans votre logiciel. Les acheteurs de logiciels, quant à eux, peuvent utiliser les SBOM pour analyser le risque inhérent à un produit grâce à des évaluations de vulnérabilité.
Les organisations seraient mieux servies en collaborant avec leurs fournisseurs pour garantir qu'ils ont accès à des informations correctes et à jour sur les composants du projet qui sont implémentés dans les systèmes et/ou les produits. Ils doivent également évaluer régulièrement leurs SBOM pour aider à minimiser les risques liés à l'utilisation de composants open source et tiers.
Échantillons SBOM
Selon le format SBOM que vous utilisez, il peut exister des différences dans les composants du SBOM. selon la taille et la complexité de votre projet, un fichier SBOM JSON peut facilement contenir des milliers de lignes ou plus. Puisque l'examen d'un fichier de mille lignes n'est pas très informatif, utilisons des exemples existants, plus simples, pour voir ce que comprend chaque format SBOM. Nous examinerons de plus près des échantillons des deux principaux formats actuellement disponibles sur le marché.
SPDX
L'exemple SPDX SBOM que nous suivrons peut être trouvé ici.
Le JSON commence par des informations générales sur le fichier lui-même – les métadonnées.
Après cela, nous obtenons les métadonnées sur le logiciel que nous examinons :
Notez la somme de contrôle et sa valeur. Chaque section du SBOM comprend le cryptage et le résultat de la partie en question afin que les personnes examinant le fichier puissent être sûres que le logiciel ou le composant mentionné est identique à celui qu'elles consultent.
Sans cette garantie, vous pourriez facilement trouver plusieurs copies portant le même nom de composants ou de logiciels et vous n'auriez aucune idée de laquelle de ces versions a été vérifiée ou incluse dans le logiciel ou le SBOM le décrivant.
Suite à la description du logiciel vérifié, nous pouvons commencer à voir les composants :
Vous pouvez voir plusieurs champs inclus pour décrire la licence d'un composant, sa page d'accueil, sa version, son nom complet, etc.
Une autre chose que vous pouvez trouver dans un format SPDX sont les annotations – des ajouts effectués ultérieurement à une section et incluant plus d'informations et parfois même du texte libre :
Pour en savoir plus sur ce format et ses capacités, vous pouvez visiter le Page SPDX de la Fondation Linux.
CycloneDX
Le format CycloneDX SBOM peut être décrit dans un fichier JSON, un fichier XML ou dans des tampons de protocole. Pour que les choses restent uniformes et simples, nous suivrons un exemple simplifié de CycloneDX JSON. L'exemple décrit peut être trouvé ici.
Le JSON commence par des informations générales sur les métadonnées du fichier.
Ensuite, les métadonnées sur le logiciel examinées :
Après cela, les composants logiciels et leurs dépendances :
Gardez à l’esprit qu’il s’agit d’un exemple simplifié et que le format peut inclure de nombreuses autres informations. Pour un aperçu plus complet des différents cas d'utilisation, vous pouvez consulter la page des cas d'utilisation OWASP CyclonDX. ici.
Voici un exemple de cette page illustrant la création d'une liste de dépendances :
Et voici une description plus large des différents composants de ce format tirée de l'OWASP Capacités de nomenclature page:
Comment utiliser un SBOM
Ne vous sentez pas mal si vous ne pouvez pas suivre les exemples de fichiers vus ici. Même si les fichiers JSON sont parfaitement lisibles par les humains, ils sont bien plus adaptés à une lecture automatique afin que des logiciels spécialisés puissent ingérer les informations et restituer les résultats fournis par l'analyse.
Vous pouvez utiliser une liste de composants logiciels pour vérifier qu'elle ne comporte aucune licence open source indésirable (ligne GPL3.0 ou MPL1.1). Vous pouvez consulter régulièrement une liste de dépendances pour voir si des mises à jour sont disponibles, ou vérifier les noms des packages par rapport aux bases de données de vulnérabilités pour savoir quelles dépendances problématiques incluent votre logiciel.
Cela peut sembler compliqué d'ingérer un SBOM et de récupérer toutes ces informations, mais n'oubliez pas que vous n'êtes pas obligé de tout faire vous-même. Des services tels que la plateforme Scribe Security peuvent éliminer de nombreux maux de tête et offrir bien plus d'avantages. N'hésitez pas à consulter notre plateforme et découvrez comment vous pouvez gérer vos risques en utilisant notre système de surveillance continue tout au long de votre cycle de vie de développement et de vos produits finaux.