Qu'est-ce qu'une nomenclature logicielle (SBOM) ?

Une nomenclature logicielle (SBOM) est un document qui fournit un inventaire détaillé des composants et des dépendances utilisés dans un projet logiciel. Il répertorie également toutes les bibliothèques, frameworks et leurs versions respectives qui sont utilisés dans le logiciel. En matière de logiciels open source (OSS) , un SBOM peut jouer un rôle crucial pour garantir la transparence, la sécurité et la conformité.

Pourquoi votre organisation devrait utiliser les SBOM ?

L’utilisation d’un SBOM, en particulier dans l’OSS, permet à une organisation d’obtenir une visibilité sur les composants et les dépendances, d’améliorer la gestion des risques et bien plus encore. Ci-dessous, nous décrivons ces avantages.

Visibilité des composants

Les OSS intègrent souvent divers composants et dépendances tiers. Un SBOM permet aux développeurs et aux utilisateurs d'avoir une visibilité claire sur tous les composants utilisés dans le logiciel. Cela inclut les bibliothèques et les frameworks open source, ainsi que leurs versions spécifiques. Cette visibilité permet de comprendre la composition du logiciel, d’identifier les vulnérabilités potentielles et de suivre les obligations de licence associées aux composants open source.

Gestion de la vulnérabilité

Comme tout autre logiciel, les logiciels libres peuvent être exposés à des vulnérabilités de sécurité. Avec un SBOM, les organisations peuvent suivre les versions des composants open source et rester informées de toutes les vulnérabilités connues associées à ces versions. Cela permet une gestion proactive des vulnérabilités en appliquant rapidement des correctifs ou des mises à jour pour atténuer et signaler tout problème de sécurité (voir RFC8615 ). En disposant d’un SBOM à jour, les organisations peuvent évaluer l’impact des vulnérabilités et prendre les mesures appropriées pour sécuriser leurs logiciels.

Sécurité de la chaîne d'approvisionnement

Ces dernières années, la sécurité de la chaîne d’approvisionnement en logiciels est devenue une préoccupation majeure. Un SBOM contribue à améliorer la sécurité de la chaîne d'approvisionnement en offrant une transparence sur les composants utilisés dans le logiciel et leurs origines. Il permet également aux organisations d’évaluer la fiabilité et la sécurité des composants sur lesquels elles s’appuient. Avec un SBOM, les organisations peuvent identifier et atténuer les risques associés aux composants compromis ou malveillants, réduisant ainsi le potentiel d’attaques de la chaîne d’approvisionnement logicielle.

Collaboration et gestion des correctifs

L'OSS encourage la collaboration et l'engagement communautaire. Un SBOM facilite une collaboration efficace en fournissant une compréhension commune des composants du logiciel entre les différents contributeurs et parties prenantes. Il aide à coordonner les efforts de gestion des correctifs en identifiant clairement les composants qui nécessitent des mises à jour ou des correctifs. La collaboration au sein de la communauté open source devient plus efficace lorsque tous les participants peuvent se référer à un SBOM partagé pour traiter les vulnérabilités de sécurité et d’autres problèmes.

Conformité réglementaire

Dans certains secteurs, les cadres réglementaires exigent que les organisations démontrent leur transparence et leur contrôle sur les composants logiciels utilisés dans leurs applications ou systèmes. Un SBOM fournit la documentation nécessaire pour satisfaire à ces exigences de conformité. Il permet aux organisations de démontrer leur diligence raisonnable, leur traçabilité et leur conformité aux réglementations en vigueur, notamment en ce qui concerne les aspects de sécurité et de licence des OSS.

Conformité des licences

Les logiciels libres sont généralement régis par des licences spécifiques qui dictent la manière dont le logiciel peut être utilisé, modifié et distribué. Un SBOM fournit un aperçu complet de tous les composants open source et de leurs licences correspondantes. Cela aide les organisations à garantir la conformité avec les conditions de licence des OSS qu’elles utilisent. En comprenant les obligations de licence, les organisations peuvent prendre des décisions éclairées sur la distribution et l’utilisation de leurs logiciels tout en évitant tout problème juridique ou de conformité.

Exigences SBOM dans les secteurs hautement réglementés

Plusieurs gouvernements et organisations dans des secteurs hautement réglementés, tels que les banques et les soins de santé, préconisent l’utilisation de SBOM ou envisagent de rendre l’utilisation d’un SBOM obligatoire, soit en interne, soit pour leurs fournisseurs.

Exemples d'industries utilisant des SBOM

Qui fait partie d'une équipe SBOM ?

La création d’un SBOM nécessite la collaboration et l’implication de diverses parties prenantes tout au long de la chaîne d’approvisionnement des logiciels. En impliquant ces parties prenantes et en favorisant la collaboration entre elles, les organisations peuvent créer un SBOM robuste et fiable qui capture les informations nécessaires sur les composants logiciels, améliore la sécurité de la chaîne d’approvisionnement et facilite les efforts de gestion des risques et de conformité.

Voici quelques personnes ou rôles clés qui devraient être impliqués dans le processus :

  • Équipe de développement – L’équipe de développement, comprenant les ingénieurs logiciels et les développeurs, joue un rôle crucial dans l’identification et la documentation des composants logiciels utilisés dans le projet. Ils sont responsables de fournir des informations précises sur les dépendances, les versions et les origines des composants logiciels qu'ils utilisent.
  • Chefs de projet – Les chefs de projet supervisent l’ensemble du processus de développement logiciel et doivent être impliqués dans l’élaboration d’un SBOM. Ils peuvent se coordonner avec l’équipe de développement pour garantir que les informations nécessaires sont collectées et documentées dans le SBOM. Les chefs de projet jouent également un rôle important en garantissant le respect des exigences SBOM et en les intégrant dans le flux de travail du projet.
  • Équipe de sécurité – L’équipe de sécurité, comprenant des analystes et des spécialistes de la sécurité, joue un rôle essentiel dans l’évaluation et la gestion des risques de sécurité associés aux composants logiciels. Ils peuvent fournir des informations sur les vulnérabilités et les problèmes de sécurité connus liés aux composants répertoriés dans votre SBOM. Leur expertise permet d’identifier les risques potentiels en matière de sécurité et de prioriser les efforts de remédiation.
  • Équipe d’approvisionnement – L’équipe d’approvisionnement, ou les personnes responsables de l’approvisionnement des composants logiciels, joue un rôle essentiel dans la création d’un SBOM. Ils peuvent fournir des informations sur l’origine et les détails de licence des composants obtenus à partir de sources externes. La collaboration avec l’équipe d’approvisionnement garantit un suivi et une vérification précis des composants logiciels au sein de la chaîne d’approvisionnement.
  • Équipe d’exploitation – L’équipe d’exploitation est souvent responsable du déploiement et de la maintenance du logiciel. Lors de la création d'un SBOM, ils peuvent apporter des informations précieuses sur l'environnement d'exécution, les configurations de déploiement et tous les composants logiciels supplémentaires introduits pendant la phase opérationnelle. Leurs connaissances garantissent un SBOM complet et à jour.
  • Experts juridiques et de conformité – Les professionnels du droit et de la conformité sont des acteurs essentiels dans l’élaboration d’un SBOM, notamment en ce qui concerne les considérations relatives aux licences et à la propriété intellectuelle. Ils peuvent fournir des conseils sur la conformité des licences et garantir que votre SBOM est conforme à toutes les exigences ou restrictions légales associées aux composants logiciels.
  • Fournisseurs et partenaires externes – Si le projet logiciel intègre des composants ou des services de fournisseurs ou de partenaires externes, il est essentiel de les impliquer dans le processus SBOM. Ils peuvent fournir les informations nécessaires sur leurs offres, notamment les dépendances, les versions et les vulnérabilités. La collaboration avec les intervenants externes permet de garantir un SBOM complet et précis.
Comment créer un SBOM

Les organisations doivent aspirer à créer un SBOM qui offre une vue complète des composants logiciels, de leurs origines, de leurs dépendances et des informations de sécurité associées. Cela permet une meilleure gestion des risques de la chaîne d’approvisionnement en logiciels et améliore la sécurité globale des logiciels.

Voici les étapes clés lors de la création d’un SBOM :

  • Identifier et inventorier les composants : Commencez par identifier chaque composant logiciel utilisé dans votre projet, y compris les composants propriétaires et open source. Créez une liste d’inventaire qui comprend des informations telles que le nom, la version et l’origine de chaque composant.
  • Déterminer l’origine des composants : Pour chaque composant, déterminez son origine, qu’elle soit propriétaire, open source ou une combinaison des deux. Cette étape permet d’évaluer les vulnérabilités de sécurité potentielles associées aux différents composants.
  • Dépendances des documents : Documentez les dépendances entre les composants, y compris toutes les bibliothèques ou frameworks utilisés. Cela permet de comprendre les relations entre les différents composants et garantit que toutes les dépendances sont prises en compte.
  • Recueillir des métadonnées : Collectez des métadonnées pour chaque composant, telles que les informations de licence, les vulnérabilités connues et les dates de sortie. Ces informations sont cruciales pour suivre les aspects de sécurité et de conformité des composants logiciels.
  • Automatiser la génération SBOM : Pour rationaliser le processus, envisagez d’automatiser la génération de SBOM à l’aide d’outils spécialisés. Ces outils peuvent analyser votre projet logiciel, identifier les composants et collecter automatiquement les informations nécessaires.
  • Maintenez votre SBOM à jour : À mesure que votre projet logiciel évolue, il est essentiel de maintenir votre SBOM à jour. Révisez et mettez à jour régulièrement l’inventaire, les origines des composants, les dépendances et les métadonnées à mesure que des changements se produisent.
  • Partagez et utilisez votre SBOM : Partagez votre SBOM avec les parties prenantes concernées de votre chaîne d'approvisionnement en logiciels, telles que les fournisseurs, les clients et les auditeurs. Cela favorise la transparence, permet une meilleure évaluation des risques et aide à identifier et à traiter les vulnérabilités.
  • Surveiller et gérer les vulnérabilités : Surveillez en permanence les nouvelles vulnérabilités et les mises à jour de sécurité liées aux composants de votre SBOM. Restez informé des derniers correctifs de sécurité et corrigez rapidement toute vulnérabilité pour maintenir la sécurité de votre logiciel.
Sept façons dont un SBOM peut échouer à tenir ses promesses

Il existe plusieurs façons pour qu'un SBOM échoue ou ne réponde pas à son objectif initial. Relever ces défis et garantir l’exactitude, l’exhaustivité et l’actualité de votre SBOM peut contribuer à atténuer le risque d’échec.

Voici quelques causes courantes d’échec qui reflètent les meilleures pratiques pour la création d’un SBOM :

  • Inventaire incomplet ou inexact : Si votre SBOM ne capture pas avec précision tous les composants logiciels utilisés dans un projet ou contient des informations incomplètes, cela peut entraîner des angles morts et des lacunes dans la compréhension de la chaîne d'approvisionnement logicielle. Un inventaire manquant ou inexact peut entraîner la négligence de vulnérabilités ou de dépendances, compromettant ainsi l'efficacité de votre SBOM.
  • Manque de visibilité des composants : Si votre SBOM ne parvient pas à fournir une visibilité claire sur les origines, les versions et les dépendances des composants logiciels, il devient difficile d’évaluer et de gérer efficacement les risques associés. Sans visibilité complète, il devient difficile de suivre les vulnérabilités, d’identifier les mises à jour des correctifs et de garantir la conformité aux exigences de licence.
  • Processus manuels et obsolètes : S’appuyer sur des processus manuels pour créer et maintenir un SBOM peut entraîner des inefficacités et des erreurs. Si votre SBOM n’est pas régulièrement mis à jour pour refléter les changements du projet logiciel, il devient rapidement obsolète et perd sa valeur en tant que référence fiable à des fins de sécurité et de conformité.
  • Métadonnées et contexte insuffisants : Un SBOM doit fournir plus qu’une simple liste de composants logiciels : il doit inclure des métadonnées pertinentes telles que les informations de licence, les vulnérabilités connues et les dates de sortie. Si ce contexte supplémentaire est manquant ou incomplet, cela entrave la capacité à évaluer les risques avec précision et à prendre des décisions éclairées.
  • Manque de collaboration des parties prenantes : La collaboration et le partage d’informations entre les parties prenantes de la chaîne d’approvisionnement en logiciels sont essentiels pour une utilisation efficace du SBOM. En cas de manque de coopération ou de réticence à partager les informations SBOM, il devient difficile d’identifier et de traiter les vulnérabilités collectivement, ce qui compromet la sécurité globale du logiciel.
  • Outillage et automatisation limités : La création et la maintenance manuelles d'un SBOM peuvent prendre du temps et être sujettes aux erreurs. Sans outils et automatisation appropriés, il devient difficile de générer, de mettre à jour et de gérer efficacement votre SBOM. Le manque d’automatisation peut également entraîner des retards dans l’identification de nouvelles vulnérabilités ou dépendances.
  • Surveillance inadéquate de la vulnérabilité : Un SBOM doit être complété par un processus robuste de surveillance des vulnérabilités. En l’absence de surveillance régulière des nouvelles vulnérabilités et des mises à jour de sécurité associées aux composants logiciels, les risques potentiels peuvent passer inaperçus, laissant le logiciel exposé à des vulnérabilités connues.
Résumé

Dans l’ensemble, un SBOM est un outil précieux pour gérer les complexités des OSS. Il favorise la transparence, la sécurité, la conformité et la collaboration au sein de l'écosystème open source. En fournissant un inventaire détaillé des composants logiciels, de leurs versions et des informations de licence associées, un SBOM permet aux organisations de prendre des décisions éclairées, de gérer les risques et de garantir l'intégrité et la sécurité de leurs projets logiciels.