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. Elle répertorie également l’ensemble des bibliothèques et des frameworks employés dans le logiciel, ainsi que leurs versions respectives. Dans le cas des logiciels open source (OSS), une SBOM peut jouer un rôle crucial pour garantir la transparence, la sécurité et la conformité.

Pourquoi votre organisation devrait utiliser des SBOM

L’utilisation d’une SBOM, notamment dans les logiciels open source, permet à une organisation de mieux connaître ses composants et ses dépendances, d’améliorer la gestion des risques, et bien plus encore. Nous présentons ces avantages ci-dessous.

Visibilité des composants

Les logiciels open source intègrent souvent divers composants et dépendances tiers. Une nomenclature logicielle (SBOM) permet aux développeurs et aux utilisateurs de connaître clairement tous les composants utilisés dans le logiciel, notamment les bibliothèques et frameworks open source, ainsi que leurs versions précises. Cette visibilité aide à comprendre la composition du logiciel, à identifier les vulnérabilités potentielles et à assurer le suivi des obligations liées aux licences des composants open source.

Gestion des vulnérabilités

Comme tout autre logiciel, les logiciels open source peuvent présenter des vulnérabilités de sécurité. Grâce à une nomenclature des composants logiciels (SBOM), les organisations peuvent suivre les versions des composants open source et se tenir informées des vulnérabilités connues qui leur sont associées. Elles peuvent ainsi gérer les vulnérabilités de manière proactive en appliquant rapidement des correctifs ou des mises à jour afin d’atténuer et de signaler tout problème de sécurité (voir RFC8615). En disposant d’une SBOM à jour, les organisations peuvent évaluer l’incidence 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 logicielle est devenue une préoccupation majeure. Une nomenclature logicielle (SBOM) contribue à renforcer cette sécurité en assurant la transparence sur les composants utilisés dans les logiciels et leur provenance. Elle permet également aux organisations d’évaluer la fiabilité et le niveau de sécurité des composants dont elles dépendent. Grâce à une SBOM, les organisations peuvent identifier et atténuer les risques liés à des composants compromis ou malveillants, réduisant ainsi le risque d’attaques visant la chaîne d’approvisionnement logicielle.

Collaboration et gestion des correctifs

Les logiciels open source favorisent la collaboration et l’implication de la communauté. Une nomenclature logicielle (SBOM) facilite une collaboration efficace en permettant aux différents contributeurs et parties prenantes de partager une compréhension commune des composants du logiciel. Elle aide à coordonner la gestion des correctifs en identifiant clairement les composants qui nécessitent des mises à jour ou des corrections. La collaboration au sein de la communauté open source gagne en efficacité lorsque tous les participants peuvent s’appuyer sur une SBOM commune pour remédier aux vulnérabilités de sécurité et à d’autres problèmes.

Conformité réglementaire

Dans certains secteurs, les cadres réglementaires exigent des organisations qu’elles démontrent leur transparence et leur maîtrise des composants logiciels utilisés dans leurs applications ou systèmes. Une nomenclature logicielle (SBOM) fournit la documentation nécessaire pour satisfaire à ces exigences de conformité. Elle permet aux organisations de démontrer qu’elles ont fait preuve de diligence raisonnable et qu’elles respectent les exigences de traçabilité ainsi que les réglementations applicables, notamment en ce qui concerne la sécurité et les licences des logiciels open source (OSS).

Conformité des licences

Les logiciels open source sont généralement régis par des licences spécifiques qui définissent les conditions dans lesquelles ils peuvent être utilisés, modifiés et distribués. Une nomenclature logicielle (SBOM) fournit une vue d’ensemble complète de tous les composants open source et de leurs licences respectives. Elle aide ainsi les organisations à respecter les conditions des licences applicables aux logiciels open source qu’elles utilisent. En comprenant leurs obligations en matière de licences, les organisations peuvent prendre des décisions éclairées concernant la distribution et l’utilisation de leurs logiciels, tout en évitant les problèmes juridiques ou de conformité.

Exigences relatives aux SBOM dans les secteurs fortement réglementés

Plusieurs gouvernements et organisations de secteurs fortement réglementés, tels que la banque et la santé, préconisent l’utilisation des SBOM ou envisagent de la rendre obligatoire, que ce soit en interne ou pour leurs fournisseurs.

Exemples de secteurs utilisant des SBOM

Secteur public – Les États-Unis, l’Union européenne, le Royaume-Uni et le Japon figurent parmi les nombreux pays qui utilisent, réglementent ou recommandent l’utilisation des SBOM.
Technologie – De grandes entreprises technologiques comme Google, Microsoft et IBM ouvrent la voie en intégrant les SBOM à leurs propres processus de développement logiciel et en contribuant à des projets tels que le Software Package Data Exchange (SPDX), OWASP, ainsi qu’en publiant en open source un outil de génération de SBOM.
Automobile – Plusieurs grands constructeurs automobiles, tels que Ford et General Motors, mettent en œuvre des SBOM et encouragent leurs fournisseurs à fournir des SBOM pour les composants et logiciels utilisés dans les systèmes automobiles.
Santé – Les fabricants de dispositifs médicaux présents sur le marché américain utilisent désormais des SBOM afin de se conformer à une réglementation de 2022 de la Food and Drug Administration.

Qui fait partie d’une équipe SBOM ?

L’élaboration d’une SBOM nécessite la collaboration et la participation de diverses parties prenantes tout au long de la chaîne d’approvisionnement logicielle. En impliquant ces parties prenantes et en favorisant leur collaboration, les organisations peuvent créer une SBOM robuste et fiable qui recense les informations nécessaires sur les composants logiciels, renforce la sécurité de la chaîne d’approvisionnement et facilite les efforts de gestion des risques et de conformité.

Voici quelques personnes ou fonctions clés qui devraient être impliquées dans le processus :

Équipe de développement – L’équipe de développement, qui comprend les ingénieurs logiciels et les développeurs, joue un rôle essentiel 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 l’origine des composants logiciels qu’elle utilise.
Chefs de projet – Les chefs de projet supervisent l’ensemble du processus de développement logiciel et doivent participer à l’élaboration d’une SBOM. Ils peuvent se coordonner avec l’équipe de développement afin de veiller à ce que les informations nécessaires soient recueillies et consignées dans la SBOM. Les chefs de projet jouent également un rôle important pour garantir le respect des exigences relatives à la SBOM et son intégration dans le flux de travail du projet.
Équipe de sécurité – L’équipe de sécurité, notamment les analystes et les 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 mesures correctives.
Équipe des achats – L’équipe des achats, ou les personnes chargées de l’approvisionnement en composants logiciels, joue un rôle essentiel dans l’élaboration d’une nomenclature logicielle (SBOM). Elle peut fournir des informations sur l’origine et les modalités de licence des composants obtenus auprès de sources externes. La collaboration avec l’équipe des achats garantit un suivi précis et une vérification rigoureuse des composants logiciels au sein de la chaîne d’approvisionnement.
Équipe d’exploitation – L’équipe d’exploitation est souvent chargée du déploiement et de la maintenance du logiciel. Lors de l’élaboration d’une 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 pendant la phase d’exploitation. Son expertise permet de garantir une SBOM exhaustive et à jour.
Experts juridiques et de la conformité – Les professionnels du droit et de la conformité sont des parties prenantes essentielles dans l’élaboration d’une SBOM, notamment pour les questions de licences et de propriété intellectuelle. Ils peuvent fournir des conseils sur le respect des licences et veiller à ce que votre SBOM soit 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 provenant de fournisseurs ou de partenaires externes, il est essentiel de les associer au processus de création de la 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 parties prenantes externes contribue à garantir une SBOM complète et précise.

Comment créer une SBOM

Les organisations devraient s’efforcer d’élaborer une nomenclature logicielle (SBOM) offrant une vue d’ensemble complète des composants logiciels, de leur origine, de leurs dépendances et des informations de sécurité associées. Elles pourront ainsi mieux gérer les risques liés à la chaîne d’approvisionnement logicielle et renforcer la sécurité globale des logiciels.

Voici les principales étapes à suivre pour créer une SBOM :

Identifier et inventorier les composants : commencez par identifier chaque composant logiciel utilisé dans votre projet, qu’il soit propriétaire ou 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éterminez son origine, qu’il soit propriétaire, open source ou qu’il combine les deux. Cette étape permet d’évaluer les éventuelles vulnérabilités de sécurité associées aux différents composants.
Documenter les dépendances : documentez les dépendances entre les composants, notamment les bibliothèques ou frameworks utilisés. Cela permet de comprendre les relations entre les différents composants et de s’assurer que toutes les dépendances sont prises en compte.
Collecter les métadonnées : collectez les métadonnées de chaque composant, telles que les informations de licence, les vulnérabilités connues et les dates de publication. Ces informations sont essentielles pour assurer le suivi de la sécurité et de la conformité des composants logiciels.
Automatisez la génération de la SBOM : pour simplifier le processus, envisagez d’automatiser la génération de la SBOM à l’aide d’outils spécialisés. Ces outils peuvent analyser votre projet logiciel, identifier les composants et recueillir automatiquement les informations nécessaires.
Maintenez votre SBOM à jour : à mesure que votre projet logiciel évolue, il est essentiel de maintenir votre SBOM à jour. Examinez et actualisez régulièrement l’inventaire, l’origine des composants, les dépendances et les métadonnées au fil des changements.
Partagez et exploitez votre SBOM : partagez votre SBOM avec les parties prenantes concernées de votre chaîne d’approvisionnement logicielle, telles que les fournisseurs, les clients et les auditeurs. Cela favorise la transparence, permet une meilleure évaluation des risques et facilite l’identification et la correction des vulnérabilités.
Surveillez et gérez les vulnérabilités : surveillez en permanence l’apparition de nouvelles vulnérabilités et les mises à jour de sécurité concernant les composants de votre SBOM. Tenez-vous informé des derniers correctifs de sécurité et remédiez rapidement à toute vulnérabilité afin de préserver la sécurité de votre logiciel.

Sept raisons pour lesquelles une SBOM peut ne pas tenir ses promesses

Une nomenclature logicielle (SBOM) peut échouer ou ne pas remplir pleinement son objectif de plusieurs façons. Relever ces défis et veiller à l’exactitude, à l’exhaustivité et à l’actualisation de votre SBOM peut contribuer à réduire le risque d’échec.

Voici quelques causes courantes d’échec qui font écho aux bonnes pratiques de création d’une SBOM :

Inventaire incomplet ou inexact : si votre SBOM ne recense pas avec précision tous les composants logiciels utilisés dans un projet ou contient des informations incomplètes, cela peut créer des angles morts et des lacunes dans la compréhension de la chaîne d’approvisionnement logicielle. Un inventaire incomplet ou inexact peut conduire à négliger des vulnérabilités ou des dépendances, ce qui compromet l’efficacité de votre SBOM.
Manque de visibilité sur les composants : si votre SBOM ne fournit pas une visibilité claire sur l’origine, 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 est difficile de suivre les vulnérabilités, d’identifier les mises à jour correctives et de garantir le respect des exigences en matière de licences.
Processus manuels et obsolètes : le recours à des processus manuels pour créer et tenir à jour une SBOM peut entraîner des inefficacités et des erreurs. Si votre SBOM n’est pas régulièrement mise à jour pour refléter les changements apportés au projet logiciel, elle devient rapidement obsolète et perd sa valeur en tant que référence fiable en matière de sécurité et de conformité.
Métadonnées et contexte insuffisants : une SBOM ne doit pas se limiter à une liste de composants logiciels. Elle doit également inclure des métadonnées pertinentes, telles que les informations relatives aux licences, les vulnérabilités connues et les dates de publication. Si ce contexte supplémentaire est absent ou incomplet, il devient plus difficile d’évaluer précisément les risques et de prendre des décisions éclairées.
Manque de collaboration entre les parties prenantes : la collaboration et le partage d’informations entre les parties prenantes de la chaîne d’approvisionnement logicielle sont essentiels à une utilisation efficace des SBOM. En cas de coopération insuffisante ou de réticence à partager les informations des SBOM, il devient difficile d’identifier et de corriger collectivement les vulnérabilités, ce qui compromet la sécurité globale du logiciel.
Outils et automatisation limités : la création et la maintenance manuelles d’une SBOM peuvent prendre beaucoup de temps et être sources d’erreurs. Sans outils ni 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 retarder l’identification de nouvelles vulnérabilités ou dépendances.
Surveillance inadéquate des vulnérabilités : une SBOM doit être complétée par un processus robuste de surveillance des vulnérabilités. En l’absence d’une surveillance régulière des nouvelles vulnérabilités et des mises à jour de sécurité associées aux composants logiciels, certains risques potentiels peuvent passer inaperçus, laissant ainsi le logiciel exposé à des vulnérabilités connues.

Résumé

Dans l’ensemble, une nomenclature logicielle (SBOM) est un outil précieux pour gérer la complexité des logiciels open source (OSS). Elle 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, une 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.

Contenu associé