Créer une nomenclature logicielle (SBOM) pour sécuriser la chaîne d’approvisionnement logicielle open source
14 mars 2022
0 minutes de lectureAujourd’hui plus que jamais, les développeurs créent des applications web en s’appuyant sur des bibliothèques logicielles open source. Pourtant, même si ces bibliothèques constituent les composants de la nomenclature logicielle (SBOM), les développeurs et les parties prenantes ne mesurent pas tous l’impact majeur de l’intégration de bibliothèques tierces sur la sécurité de la chaîne d’approvisionnement logicielle open source. À partir de ce constat, explorons la sécurité des SBOM et l’importance de les suivre pour les applications que vous développez.
Les enjeux de sécurité de la chaîne d’approvisionnement logicielle sont devenus une préoccupation croissante pour les organisations comme pour les gouvernements. Le rapport Threat Landscape for Supply Chain Attacks, publié par l’Agence de l’Union européenne pour la cybersécurité (ENISA), estime que les attaques contre les chaînes d’approvisionnement logicielles ont augmenté de 400 % en 2021.
La grande disponibilité des logiciels open source pour les développeurs et la facilité d’importation de composants logiciels contribuent toutes deux à accroître les risques de sécurité et les risques juridiques pour les développeurs, et par conséquent pour leur entreprise. Il est donc essentiel de sensibiliser les développeurs et les équipes de sécurité et de leur proposer des solutions avancées de sécurité de la chaîne d’approvisionnement.
Avant d’aller plus loin, passons en revue quelques notions fondamentales sur les SBOM et clarifions les termes techniques utilisés dans cet article.
Qu’est-ce qu’une nomenclature logicielle ?
Une nomenclature logicielle, souvent abrégée en SBOM, est une liste complète de tous les composants logiciels utilisés au sein d’une organisation. Elle regroupe les bibliothèques open source tierces, les packages fournis par des éditeurs et les artefacts développés par l’organisation elle-même.
Pourquoi créer une SBOM ?
Une SBOM est essentiellement un inventaire de tous les composants logiciels utilisés dans vos applications. Sans elle, vous ne pouvez pas connaître les risques liés aux licences ni les risques de sécurité associés aux logiciels que vous développez ou utilisez. Il est essentiel de tenir à jour une nomenclature logicielle conforme au format SBOM pour suivre le rythme rapide du développement logiciel, où les composants et leurs versions évoluent sans cesse.
Qu’est-ce que CycloneDX ?
OWASP CycloneDX est une norme de nomenclature logicielle (SBOM) conçue pour les contextes de sécurité des applications et l’analyse des composants de la chaîne d’approvisionnement. Elle fournit un inventaire de tous les composants logiciels internes et tiers. Cette spécification complète va au-delà des bibliothèques logicielles et couvre des normes telles que la nomenclature des logiciels en tant que service (SaaSBOM), le Vulnerability Exploitability Exchange (VEX), et bien plus encore. Il s’agit d’un projet open source sous licence Apache 2.0, ouvert à la collaboration sur le dépôt GitHub open source suivant : https://github.com/CycloneDX/specification.
Les enjeux de sécurité qui obligent les développeurs à tenir une nomenclature logicielle à jour
La nomenclature logicielle n’est pas une notion qui parle spontanément aux développeurs. Traditionnellement, cette tâche était réservée aux équipes chargées de la sécurité et de l’évaluation des risques au sein d’une organisation. Mais la donne a changé avec l’essor considérable des composants logiciels open source, comme en témoigne le registre de packages npm, qui compte plus de 1 800 000 packages gratuits et open source.
Si vous êtes développeur et que vous vous demandez pourquoi créer une SBOM pour tous les composants logiciels que vous utilisez, rappelons quelques incidents de sécurité très médiatisés survenus ces dernières années à cause de bibliothèques logicielles open source :
event-stream : ce package npm populaire a été compromis et du code malveillant y a été ajouté.
Log4Shell : une vulnérabilité d’exécution de code à distance très grave a été découverte dans Log4j, la bibliothèque de journalisation Java populaire. Cette vulnérabilité existait depuis sept ans avant d’être découverte !
Lorsque ces vulnérabilités ou incidents de sécurité sont découverts ou surviennent, et que votre application utilise l’une des versions vulnérables, qui est chargé de mettre à niveau ces bibliothèques et de publier une nouvelle version ? Vous l’avez deviné : les développeurs.
Même si l’équipe de sécurité gère sa propre nomenclature logicielle, lorsqu’elle détecte de tels problèmes, elle donne l’alerte, prévient les équipes concernées et demande aux développeurs de mettre à niveau les versions vulnérables. Mais à l’heure des workflows avancés, ne pouvons-nous pas automatiser l’ensemble du processus et l’intégrer plus naturellement aux workflows des développeurs ? Bien sûr. C’est précisément ce que propose Snyk, dont l’utilisation est gratuite.
Pourquoi les développeurs devraient-ils se soucier des conséquences juridiques de leur nomenclature logicielle ?
Aujourd’hui, les aspects juridiques de l’utilisation des logiciels ne sont sans doute pas la première chose à laquelle pensent les développeurs lorsqu’ils expérimentent avec leur code et créent des applications. Pourtant, il y a quelques décennies, la situation était différente. Les développeurs et leurs équipes accordaient une grande attention à la licence spécifique des composants logiciels intégrés à leur code. Qu’est-ce qui a changé ? À l’époque, les licences les plus courantes étaient de type copyleft, comme la GNU General Public License (GPL), qui imposait plusieurs restrictions à la distribution des logiciels. En résumé, la GPL a un effet en cascade : tout code créé à partir d’un composant sous licence GPL devient automatiquement lui-même soumis à la GPL — un élément à prendre en compte lors de l’élaboration de votre modèle économique.
Une vingtaine d’années plus tard, nous avons constaté un net recul des licences copyleft. En 2015, la licence la plus utilisée dans les dépôts open source créés sur GitHub était la licence MIT. Comme d’autres licences, la licence MIT appartient à la famille des licences permissives : elle lève bon nombre des restrictions liées à l’utilisation des logiciels et offre davantage de liberté aux développeurs qui les utilisent.
Nous vivons une période de l’histoire des logiciels open source marquée par une adoption massive et par la publication de nouveaux logiciels sous des licences très permissives. Avons-nous pris l’habitude de considérer l’open source comme la norme ? Tenons-nous désormais les licences open source pour acquises ?
Deux affaires très médiatisées liées à des questions juridiques sur la licence des projets ont préoccupé les développeurs :
React, la bibliothèque de vues JavaScript open source très populaire, a changé de licence : elle est passée de sa propre version de « BSD + Patents grant » à la licence permissive MIT, après que l’Apache Software Foundation a interdit le projet React, jugeant la licence de Facebook trop restrictive. Ce changement a également suscité des protestations de développeurs du monde entier, qui envisageaient d’abandonner complètement le projet au profit d’alternatives comme Preact. Quincy Larson propose une chronologie utile des événements dans cet article de freeCodeCamp.
Elastic, l’entreprise et le projet open source éponymes, à l’origine du célèbre outil de recherche et de l’ELK Stack, a également dû faire face à des changements de licence, sous l’effet de la concurrence croissante des fournisseurs cloud et de ses conséquences sur l’activité d’Elastic.
En tant que développeur utilisant React, Elastic ou d’autres bibliothèques logicielles open source, vous devrez très probablement prévoir la migration d’un projet vers un autre en cas de problème de licence.
Par ailleurs, que se passe-t-il si vous créez des applications et livrez des logiciels dont l’un des composants imbriqués est soumis à une licence copyleft ? Les écosystèmes JavaScript et Node.js sont connus pour le grand nombre de packages npm installés. Le risque pour l’entreprise est bien réel et mérite votre attention. En tant que développeur, vous devez pouvoir suivre et comprendre les licences logicielles utilisées dans vos projets.
Les applications que vous développez et les logiciels que vous utilisez contiennent probablement déjà des références à leurs licences. Par exemple, si vous développez un projet JavaScript, les informations de licence figurent dans le fichier manifeste package.json :
La licence indiquée dans ce fichier package.json utilise le format SBOM courant appelé SPDX afin de garantir sa conformité aux normes internationales et d’interopérabilité entre outils.
Qu’est-ce que SPDX ?
Le Software Package Data Exchange (SPDX) est un projet collaboratif de la Linux Foundation qui définit un format SBOM standard commun pour suivre les nomenclatures logicielles et faciliter la création de rapports interopérables à l’aide de différents outils. Plus précisément, la liste des licences SPDX fournit un identifiant commun pour chaque licence ainsi que son URL canonique.
La page web de la liste des licences SPDX ci-dessous répertorie toutes les licences et leurs identifiants :
Snyk propose des fonctionnalités d’audit open source qui, à l’image du tableau ci-dessus, génèrent des rapports de nomenclature logicielle pour réaliser un audit logiciel complet, interactif, consultable et doté de filtres.
Standardiser l’utilisation des bibliothèques open source par les développeurs
Les organisations d’ingénierie matures passent d’une utilisation ponctuelle et opportuniste des bibliothèques open source à une utilisation réfléchie et planifiée dans leurs projets, selon des directives et des bonnes pratiques.
Par exemple, les équipes de développement JavaScript peuvent vouloir standardiser l’utilisation d’une seule dépendance pour les requêtes HTTP dans toutes les équipes, au lieu de s’appuyer sur plusieurs dépendances telles que les packages npm request, axios, node-fetch, et d’autres. L’objectif n’est pas seulement de faciliter la gestion des dépendances open source, mais aussi de centraliser les connaissances et l’expertise liées aux API, de simplifier la résolution des problèmes, et bien plus encore.
Pour votre équipe de développement, pouvez-vous répondre concrètement aux questions suivantes ?
Quelles bibliothèques open source est-ce que j’utilise le plus dans l’ensemble des projets de mon organisation R&D ?
Parmi les bibliothèques open source que nous utilisons, lesquelles sont déclarées obsolètes ?
Quelles bibliothèques open source de nos projets utilisent des licences copyleft telles que GPL-2 ?
Quelles bibliothèques open source ont été publiées il y a plus de 15 ans sans recevoir la moindre mise à jour ? Devriez-vous vous en inquiéter ?
Toutes ces informations et bien d’autres sont autant d’avantages liés à la tenue d’une nomenclature logicielle, ou SBOM. Snyk fournit également de précieuses informations sur l’état des packages open source grâce aux fonctionnalités de Snyk Open Source :
Pourquoi une SBOM accélère-t-elle votre préparation à sécuriser la chaîne d’approvisionnement ?
Qu’est-ce que la sécurité de la chaîne d’approvisionnement logicielle ?
Les enjeux traditionnels de sécurité des applications dans le cycle de vie du développement logiciel se sont étendus du code des développeurs à l’ensemble de l’infrastructure d’outils nécessaire à la création des logiciels. La surface d’attaque est ainsi devenue considérable : elle commence par l’IDE utilisé par les développeurs pour écrire leur code, englobe tous les composants open source avec lesquels ils créent leurs applications, puis s’étend aux pipelines CI/CD et à la configuration de l’infrastructure de déploiement. On pourrait même affirmer que les risques liés à la chaîne d’approvisionnement s’étendent jusqu’aux puces matérielles de l’ordinateur utilisé comme environnement de développement.
Le département du Commerce des États-Unis a publié un document conformément au décret présidentiel 14028 sur le renforcement de la cybersécurité nationale, qui cite les éléments minimaux d’une nomenclature logicielle (SBOM). Poursuivons notre exploration de la chaîne d’approvisionnement pour voir ce que nous pouvons en apprendre.
La chaîne d’approvisionnement logicielle englobe essentiellement tous les composants qui font partie du processus complet de développement logiciel. Au premier abord, vous pourriez penser qu’elle se limite aux dépendances que vous ajoutez à vos projets. C’est vrai, mais elle va bien au-delà.
Votre IDE est également un élément essentiel de votre processus de développement logiciel, n’est-ce pas ? Quel risque cela représenterait-il pour l’entreprise si votre IDE préféré contenait des portes dérobées ou des logiciels malveillants ? Et si l’une de ses extensions ou l’un de ses plug-ins présentait de graves vulnérabilités, voire contenait du code malveillant ?
Vulnérabilités dans les extensions de VS Code
Les vulnérabilités des extensions de VS Code ne sont pas qu’un risque théorique. En mai 2021, Snyk a découvert des vulnérabilités de sécurité de la chaîne d’approvisionnement dans des extensions de Visual Studio Code disponibles sur la marketplace des extensions de VS Code, qui concernaient plus de 2 000 000 de développeurs selon leur nombre de téléchargements.
Ces extensions de VS Code, comme Open in Default Browser, qui totalise plus de 520 000 téléchargements, ou Instant Markdown, qui en compte plus de 120 000, représentent une menace réelle pour les développeurs. Si un attaquant incite un développeur à cliquer sur un lien, il peut exploiter une vulnérabilité de traversée de répertoires pour accéder à des fichiers et informations sensibles dans l’environnement de développement. Dans les cas les plus graves, il suffit aux développeurs de cliquer sur un lien pour permettre aux attaquants d’exécuter des commandes à distance.
La vidéo suivante montre pourquoi la sécurité des SBOM de la chaîne d’approvisionnement logicielle est une préoccupation essentielle pour les développeurs. Elle illustre l’exploitation de l’extension Instant Markdown pour VS Code et la façon dont celle-ci vole les clés SSH sensibles d’un développeur :
Vulnérabilités de sécurité touchant les IDE Java
Si vous pensez que la sécurité de la chaîne d’approvisionnement fait des ravages dans l’écosystème JavaScript, regardez la chronologie de 24 incidents de sécurité de la chaîne d’approvisionnement publiée par l’ENISA sur une période de seulement 18 mois (de janvier 2020 à juillet 2021). Elle comprend des incidents malveillants ayant touché des développeurs Java par l’intermédiaire de l’IDE NetBeans :
Maintenir un SBOM open source sécurisé
Alors, comment atténuer les risques liés à la sécurité de la chaîne d’approvisionnement logicielle tout au long de votre cycle de vie du développement logiciel (SDLC) ? Tenir un SBOM à jour est un bon point de départ. C’est aussi une exigence imposée par le décret présidentiel américain, compte tenu des menaces considérables que les composants logiciels open source font peser sur les entreprises et les administrations.
La sécurité de la chaîne d’approvisionnement open source ne se limite pas aux menaces liées aux vulnérabilités connues et aux éventuelles vulnérabilités zero-day résultant d’actes malveillants : elle dépend aussi de la santé globale des packages. Des indicateurs tels que la fréquence des commits et des versions du projet, le nombre de tickets ouverts et la communauté de contributeurs participent tous à l’évaluation de cette santé. Ils permettent de mieux cerner la maintenance du projet et sa vulnérabilité aux activités malveillantes.
Snyk a créé Snyk Advisor pour répondre précisément à ce besoin : évaluer la santé des packages dans le cadre de la sécurité de la chaîne d’approvisionnement logicielle open source. L’outil prend actuellement en charge les métadonnées d’écosystèmes tels que JavaScript, Go et Python, ainsi que des images de conteneurs basées sur Docker. Nous vous recommandons vivement de le consulter lorsque vous recherchez des bibliothèques open source.
Générer un SBOM open source avec Snyk
Snyk Open Source analyse les manifestes de packages et les fichiers de verrouillage pour générer un graphe complet des dépendances. Cela permet de repérer les vulnérabilités dans la hiérarchie des dépendances et d’autres problèmes, comme les packages obsolètes. Toutefois, cela ne constitue pas à lui seul un SBOM.
Gareth Rushgrove, vice-président produit chez Snyk, a écrit sur l’évolution des normes SBOM avec Snyk et SPDX. Dans cet article, Gareth explique que Snyk explore différentes façons de travailler avec des outils communautaires et présente snyk2spdx, un projet open source qui convertit la sortie de la CLI Snyk au format SPDX.
Si vous appréciez l’API Snyk, Gareth recommande également de l’utiliser pour récupérer le manifeste du package d’origine et les détails des vulnérabilités, puis de convertir ces données au format SPDX.
En résumé, intégrer un SBOM aux processus de développement et de livraison logicielle est essentiel face aux enjeux actuels de sécurité de la chaîne d’approvisionnement. Il permet de répondre à des questions allant de l’inventaire à l’intégrité et à la provenance.
Nous vous recommandons vivement les articles suivants pour approfondir vos connaissances sur la sécurité de la chaîne d’approvisionnement open source et les nomenclatures logicielles :
Comprendre les exigences de sécurité de la chaîne d’approvisionnement logicielle du décret présidentiel sur la cybersécurité, par Daniel Berman
Pour approfondir la comparaison des licences, consultez la documentation Licences open source : types et comparaison.
Gérer la conformité des licences dans toute votre organisation grâce aux politiques de licences de Snyk, par Josepha Riveros
Découvrez dans la documentation Snyk une approche pratique de la gestion des politiques de licences sur la plateforme Snyk.
Sécurisez vos dépendances open source
Les outils Snyk, conçus pour les développeurs, génèrent en un clic des pull requests correctives pour vos dépendances open source vulnérables et leurs dépendances transitives.
