Qu’est-ce qu’un Software Bill of Materials (SBOM) ?

L’utilisation d’un SBOM - en particulier dans le domaine du logiciel libre - permet à une organisation d’avoir une meilleure visibilité sur les composants et les dépendances, d’améliorer la gestion des risques et bien d’autres choses encore.

Visibilité sur les composants

Les logiciels libres intègrent souvent divers composants et dépendances de tiers. Un SBOM permet aux développeurs et aux utilisateurs d’avoir une visibilité claire de tous les composants utilisés dans le logiciel, y compris les bibliothèques et les cadres libres, ainsi que leurs versions spécifiques. Cette visibilité aide à comprendre la composition du logiciel, à identifier les vulnérabilités potentielles et à suivre toutes les obligations de licence associées aux composants libres.

Gestion de la vulnérabilité

Comme tout autre logiciel, les logiciels libres peuvent présenter des failles de sécurité. Avec un SBOM, les organisations peuvent suivre les versions des composants libres et rester informées de toutes les failles connues associées à ces versions. Cela permet une gestion proactive des failles 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 failles 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 des logiciels est devenue une préoccupation majeure. Un SBOM contribue à renforcer la sécurité de la chaîne d’approvisionnement en fournissant une transparence sur les composants utilisés dans le logiciel et leur origine. Il permet également aux organisations d’évaluer la fiabilité et la posture de sécurité des composants dont elles dépendent. 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 des logiciels.

Collaboration et gestion des correctifs

Les logiciels libres encouragent la collaboration et l’implication de la communauté. 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 corrections. La collaboration au sein de la communauté des logiciels libres devient plus efficace lorsque tous les participants peuvent se référer à un SBOM partagé pour traiter les vulnérabilités en matière de sécurité et d’autres problèmes.

La conformité aux réglementations

Dans certains secteurs, les cadres réglementaires exigent des organisations qu’elles fassent preuve de transparence et de contrôle sur les composants logiciels utilisés dans leurs applications ou leurs systèmes. Un SBOM fournit la documentation nécessaire pour satisfaire à ces exigences de conformité. Il permet aux organisations de faire preuve de diligence raisonnable, de traçabilité et de conformité avec les réglementations pertinentes, en particulier en ce qui concerne les aspects de sécurité et de licence des logiciels libres.

Conformité de la licence

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 une vue d’ensemble de tous les composants open source et de leurs licences correspondantes. Cela aide les organisations à assurer la conformité avec les conditions de licence des logiciels libres 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 les problèmes juridiques ou de conformité.

Plusieurs gouvernements et organisations dans des secteurs très réglementés, tels que la banque et les soins de santé, préconisent l’utilisation de SBOM ou envisagent d’en faire une exigence, que ce soit en interne ou pour leurs fournisseurs.

Exemples d’industries utilisant des SBOM

• Secteur public : les États-Unis, l’Union européenne, le Royaume-Uni et le Japon font partie des nombreux pays qui utilisent, réglementent ou recommandent l’utilisation des SBOM.
• Technologie : de grandes entreprises technologiques telles que Google, Microsoft et IBM montrent la voie en mettant en œuvre des SBOM dans leurs propres processus de développement de logiciels, en contribuant à des projets tels que le Software Package Data Exchange (SPDX), l’OWASP et un outil de génération de SBOM en open sourcing.
• Automobile : plusieurs grandes entreprises automobiles, telles que Ford et General Motors, mettent en place des SBOM et encouragent leurs fournisseurs à délivrer des SBOM pour les composants et les logiciels utilisés dans les systèmes automobiles.
• Santé : les fabricants de dispositifs médicaux sur le marché américain utilisent désormais des SBOM pour se conformer à la réglementation de la Food and Drug Administration de 2022.

En impliquant ces parties prenantes et en favorisant la collaboration entre elles, les organisations peuvent construire un SBOM robuste et fiable qui capture les informations nécessaires sur les composants logiciels, renforce la sécurité de la chaîne d’approvisionnement et facilite la gestion des risques et les efforts de mise en 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, composée d’ingénieurs logiciels et de développeurs, joue un rôle crucial dans l’identification et la documentation des composants logiciels utilisés dans le projet. Elle est chargée de fournir des informations précises sur les dépendances, les versions et les origines des composants logiciels qu’elle utilise.
• Gestionnaires de projet : les gestionnaires de projet supervisent l’ensemble du processus de développement du logiciel et devraient être impliqués dans l’élaboration d’un SBOM. Ils peuvent assurer la coordination avec l’équipe de développement pour veiller à ce que les informations nécessaires soient rassemblées et documentées dans le SBOM. Les gestionnaires de projet jouent également un rôle important en veillant au respect des exigences du SBOM et en l’intégrant dans le flux de travail du projet.
• Équipe de sécurité : l’équipe de sécurité, composée d’analystes et de 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. Elle peut 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. Son expertise permet d’identifier les risques de sécurité potentiels et de hiérarchiser les efforts de remédiation.
• Équipe chargée de l’approvisionnement : l’équipe chargée de l’approvisionnement, ou les personnes responsables de l’achat des composants logiciels joue un rôle essentiel dans l’élaboration d’un SBOM. Elle peut fournir des informations sur l’origine et les détails des licences des composants obtenus auprès de sources externes. La collaboration avec l’équipe chargée de l’approvisionnement garantit un suivi et une vérification exacts 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 l’élaboration d’un SBOM, elle peut fournir des informations précieuses sur l’environnement d’exécution, les configurations de déploiement et tout composant logiciel supplémentaire introduit au cours de la phase d’exploitation. Leurs points de vue garantissent un SBOM complet et à jour.
• Experts juridiques et de la conformité : les professionnels juridiques et de la conformité sont des acteurs essentiels dans l’élaboration d’un SBOM, en particulier en ce qui concerne les licences et la propriété intellectuelle. Ils peuvent fournir des conseils sur la conformité des licences et veiller à ce que votre SBOM s’aligne sur toutes les exigences ou restrictions juridiques associées aux composants logiciels.
• Fournisseurs et partenaires externes : si le projet logiciel intègre des composants ou des services provenant 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, y compris les dépendances, les versions et les vulnérabilités. La collaboration avec les parties prenantes externes permet de garantir un SBOM complet et précis.

Les organisations devraient aspirer à créer un SBOM qui offre une vue d’ensemble des composants logiciels, de leurs origines, de leurs dépendances et des informations de sécurité associées. Cela permet de mieux gérer les risques de la chaîne d’approvisionnement en logiciels et d’améliorer la sécurité globale des logiciels.

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

• Identifier et faire l’inventaire des composants : commencez par identifier tous les composants logiciels utilisés dans votre projet, y compris les composants propriétaires et open source. Créez une liste d’inventaire comprenant des informations telles que le nom, la version et l’origine de chaque composant.
• Déterminer l’origine des composants : pour chaque composant, déterminer son origine, qu’elle soit propriétaire, open source ou une combinaison des deux. Cette étape permet d’évaluer les vulnérabilités potentielles en matière de sécurité associées aux différents composants.
• Documenter les dépendances : documenter les dépendances entre les composants, y compris les bibliothèques ou les cadres utilisés, afin de mieux comprendre les relations entre les différents composants et de s’assurer que toutes les dépendances sont prises en compte.
• Recueillir des métadonnées : recueillir des métadonnées pour chaque composant, telles que les informations relatives à la licence, les vulnérabilités connues et les dates de publication. Ces informations sont essentielles pour suivre les aspects de sécurité et de conformité des composants logiciels.
• Automatiser la génération du SBOM : pour rationaliser le processus, envisagez d’automatiser la génération du SBOM à l’aide d’outils spécialisés. Ces outils peuvent analyser votre projet logiciel, identifier les composants et rassembler automatiquement les informations nécessaires.
• Maintenir votre SBOM à jour : au fur et à mesure que votre projet logiciel évolue, il est essentiel de maintenir votre SBOM à jour. Examinez et mettez régulièrement à jour l’inventaire, l’origine des composants, les dépendances et les métadonnées au fur et à 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 les vulnérabilités afin de maintenir la sécurité de votre logiciel.

Il existe plusieurs façons pour un SBOM d’échouer ou de ne pas atteindre l’objectif visé. En relevant ces défis et en garantissant l’exactitude, l’exhaustivité et la mise à jour de votre SBOM, vous pouvez contribuer à atténuer le risque d’échec.

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

• Inventaire incomplet ou imprécis : si votre SBOM ne saisit pas avec précision tous les composants logiciels utilisés dans un projet ou s’il contient des informations incomplètes, il peut entraîner des angles morts et des lacunes dans la compréhension de la chaîne d’approvisionnement en logiciels. Un inventaire incomplet ou imprécis peut conduire à négliger des vulnérabilités ou des dépendances, ce qui nuit à l’efficacité de votre SBOM.
• Manque de visibilité sur les composants : si votre SBOM ne fournit pas 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 d’assurer la conformité avec les exigences en matière de licences.
• Processus manuels et obsolètes : s’appuyer sur des processus manuels pour créer et maintenir un SBOM peut être source d’inefficacité et d’erreurs. Si votre SBOM n’est pas régulièrement mis à jour pour refléter les changements dans le 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é.
• Des métadonnées et un contexte insuffisants : un SBOM ne doit pas se limiter à une simple liste de composants logiciels - il doit inclure des métadonnées pertinentes telles que des informations sur les licences, les vulnérabilités connues et les dates de publication. Si ce contexte supplémentaire est absent ou incomplet, il entrave la capacité d’évaluer les risques avec précision et de prendre des décisions en connaissance de cause.
• Manque de collaboration entre les 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 du SBOM, il devient difficile d’identifier et de traiter les vulnérabilités collectivement, ce qui compromet la sécurité globale du logiciel.
• Outil et automatisation limités : la création et la maintenance manuelles d’un SBOM peuvent prendre du temps et être source d’erreurs. Sans outil 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 des vulnérabilités : un SBOM doit être complété par un processus solide de surveillance des vulnérabilités. S’il n’y a pas 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.

Dans l’ensemble, un SBOM est un outil précieux pour gérer la complexité des logiciels libres. Il favorise la transparence, la sécurité, la conformité et la collaboration au sein de l’écosystème des logiciels libres. 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 d’assurer l’intégrité et la sécurité de leurs projets logiciels.