Créez une nomenclature des logiciels (SBOM) pour assurer la sécurité de votre chaîne d’approvisionnement open source

Jamais les développeurs n’avaient autant basé leurs applications Web sur des bibliothèques logicielles open source. Toutefois, alors même que ces bibliothèques représentent la majorité des éléments listés dans les nomenclatures, tous les développeurs et parties prenantes ne comprennent pas forcément les répercussions importantes que l’inclusion de bibliothèques tierces peut avoir sur la sécurité de la chaîne d’approvisionnement open source. C’est donc dans cette optique que nous allons nous pencher sur le sujet de la sécurité de la chaîne d’approvisionnement et de l’importance du suivi de ces composants dans les applications que vous développez.

La question de la sécurité de la chaîne d’approvisionnement logicielle pose de plus en plus souvent un vrai dilemme aux organisations et gouvernements. Le rapport Threat Landscape for Supply Chain Attacks publié par l’Agence de l’Union européenne pour la cybersécurité (ENISA), estime en effet que le nombre d’attaques contre la chaîne d’approvisionnement logicielle a augmenté de 400 % en 2021.

L’utilisation accrue de logiciels open source par les développeurs et la simplicité de l’importation de composants logiciels accroissent le risque sécuritaire et juridique pour le développeur, et indirectement, pour l’entreprise.

Mais avant d’aller plus loin, reprenons les bases des SBOM et clarifions les termes techniques que nous allons utiliser tout au long de cet article.

Qu’est-ce qu’une nomenclature des logiciels ?

Une nomenclature des logiciels, souvent désignée par l’acronyme anglais SBOM, est une liste reprenant l’ensemble des composants logiciels utilisés par une organisation. Elle se compose ainsi de bibliothèques open source tierces, de paquets de fournisseurs et d’artefacts internes développés par l’organisation.

Pourquoi créer une SBOM ?

Une SBOM fait l’inventaire des composants logiciels utilisés dans vos applications. Sans cet outil, vous n’avez aucune visibilité sur les risques de sécurité et de licence associés aux logiciels que vous développez ou utilisez. La tenue d’une nomenclature des logiciels dans un format conforme est également indispensable pour suivre le rythme soutenu du développement, car les composants et leurs versions changent rapidement.

Qu’est-ce que CycloneDX ?

OWASP CycloneDX est une norme de nomenclature des logiciels pensée pour la sécurité des applications et l’analyse des composants de la chaîne d’approvisionnement. Ce format permet de répertorier l’ensemble des composants logiciels internes et tiers. Ses spécifications sont nombreuses et vont au-delà des seules bibliothèques logicielles en incluant des formats telles que les nomenclatures de logiciels en tant que service (SaaSBOM), le Vulnerability Exploitability Exchange (VEX) et bien d’autres. La norme est un projet open source sous licence Apache 2.0 et accepte les contributions sur le référentiel GitHub open source suivant : https://github.com/CycloneDX/specification.

Problèmes de sécurité imposant aux développeurs de tenir une nomenclature des logiciels

Le terme de « nomenclature des logiciels » ne parle pas vraiment aux développeurs. En effet, sa gestion était historiquement dévolue aux équipes de sécurité et d’évaluation du risque. Néanmoins, les choses ont changé en raison de la montée en puissance impressionnante des composants logiciels open source, comme en témoigne l’existence du registre npm, qui propose plus de 1 800 000 paquets gratuits et open source.

Si vous êtes développeur et doutez d’avoir besoin d’une SBOM pour lister tous vos composants logiciels, voici quelques incidents de sécurité liés à des bibliothèques open source qui ont fait couler beaucoup d’encre ces dernières années :

1. event-stream : ce paquet populaire de npm a été compromis par des hackers qui y ont inclus du code malveillant.

2. Log4Shell : Log4j, une bibliothèque de journalisation Java très utilisée, présentait une vulnérabilité très grave permettant l’exécution de code distant. Cette vulnérabilité n’a été découverte que 7 ans après son introduction !

Lorsque des vulnérabilités de ce type sont découvertes ou que des incidents de sécurité surviennent et que votre application utilise une version vulnérable, qui doit selon vous mettre à jour les bibliothèques concernées et publier une nouvelle version de son application ? Eh oui, c’est le rôle des développeurs.

L’équipe de sécurité peut très bien travailler activement sur cette question et tenir à jour sa propre nomenclature des logiciels. Néanmoins, si elle découvre un problème de ce type, elle va alerter les équipes nécessaires et demander aux développeurs de mettre à niveau les versions vulnérables. Aujourd’hui, la gestion des workflows est devenue extrêmement sophistiquée. Ne pouvons-nous pas automatiser tout le processus pour qu’il s’intègre de manière native aux workflows de développeurs ? Bien sûr que si. Et c’est justement ce que Snyk se propose de vous aider à faire, gratuitement.

Pourquoi les développeurs devraient-ils s’intéresser aux conséquences juridiques de leur nomenclature des logiciels ?

À l’heure actuelle, les développeurs ont probablement d’autres choses en tête que des questions juridiques lorsqu’ils manipulent leur code et conçoivent des applications. Pourtant, il en allait bien autrement il y a 20 ans de cela. Les développeurs et leurs équipes étaient alors très attentifs à la licence associée aux composants logiciels qu’ils intégraient dans leur code. Mais alors, qu’est-ce qui a changé ? À l’époque, les licences les plus utilisées étaient de type copyleft, comme la licence publique générale GNU (GPL), qui présentait diverses limitations concernant la distribution des logiciels. Pour faire court, la licence GPL fonctionne en cascade : tout code qui utilise un composant soumis à cette licence est automatiquement soumis lui aussi à cette licence, un point à ne pas négliger lors de l’élaboration de votre modèle commercial.

20 ans plus tard, les licences copyleft ont moins la cote. En 2015 déjà, la licence la plus utilisée dans les référentiels open source créés sur GitHub était une licence MIT. Comme d’autres licences, la licence MIT est assez permissive et limite peu l’utilisation des logiciels. Au contraire, elle étend la liberté accordée aux développeurs.

À l’heure actuelle, les logiciels open source sont de plus en plus populaires, les nouveaux logiciels s’accompagnent donc de licences très permissives. Nous serions-nous habitués à l’utilisation de logiciels open source par défaut ? Considérons-nous les licences actuelles des logiciels open source comme un dû ?

Deux problèmes juridiques très connus concernant la licence d’utilisation de projets ont pourtant beaucoup inquiété les développeurs :

1. React, une bibliothèque d’affichage JavaScript extrêmement populaire, a dû changer de licence. Alors qu’elle était soumise à sa propre version de la licence « BSD + Patents grant », elle est passée à la licence MIT, plus permissive. En effet, l’Apache Software Foundation avait banni le projet en estimant que la licence de Facebook était trop restrictive. Cette décision est aussi liée à la pression de développeurs du monde entier, qui envisageaient de laisser tomber le projet au profit d’une autre option, par exemple le projet Preact. Quincy Larson présente la chronologie des événements de manière bien pratique dans cet article publié sur freecodecamp.

2. Elastic, entreprise et projet open source à l’origine de l’outil de recherche Elasticsearch et de la Suite ELK, a également dû procéder à des changements de licence en raison de la concurrence toujours plus féroce des éditeurs de solutions cloud.

Si vous êtes développeur et utilisez React, Elastic ou d’autres bibliothèques logicielles open source, vous aurez probablement la responsabilité de préparer la migration d’un projet à l’autre en cas de problème de licence.

Par ailleurs, que pensez-vous qu’il se passera si vous créez et distribuez des applications dont l’un des composants imbriqués est soumis à une licence copyleft ? Les écosystèmes JavaScript et Node.js sont connus pour le nombre de paquets npm qu’ils installent. Le risque pour l’entreprise est bien réel. En tant que développeur, vous devez donc être capable de connaître et comprendre les licences logicielles utilisées dans vos différents projets.

Les applications que vous créez et les logiciels que vous utilisez incluent probablement déjà des références à la licence applicable. Par exemple, si vous travaillez sur un projet JavaScript, les informations de licence se trouvent dans le fichier de manifeste package.json :

1{
2  "name": "snyk",
3  "version": "1.0.0-monorepo",
4  "description": "snyk library and cli utility",
5  "files": [
6    "help/cli-commands",
7    "dist",
8    "bin",
9    "pysrc",
10    "config.default.json",
11    "SECURITY.md",
12    "LICENSE",
13    "README.md"
14  ],
15  "author": "snyk.io",
16  "license": "Apache-2.0",

La licence décrite dans ce fichier suit le format de SBOM courant que l’on appelle SPDX pour se conformer aux normes internationales et d’interopérabilité des différents outils.

Qu’est-ce que SPDX ?

Software Package Data Exchange (SPDX) est un projet collaboratif de la Linux Foundation proposant un format standardisé de SBOM pour suivre les nomenclatures des logiciels. Avec ce format, de nombreux outils peuvent créer plus facilement des rapports d’interopérabilité. Plus spécifiquement, la liste de licences SPDX fournit un identifiant pour les licences courantes ainsi qu’une URL canonique vers chaque licence.

Vous trouverez sur cette page la liste complète de toutes les licences et leurs identifiants :

Snyk fournit des fonctions d’audit du code open source qui, comme le tableau ci-dessus, génèrent des nomenclatures des logiciels permettant d’établir un audit logiciel complet et totalement interactif, dans lequel vous pouvez faire des recherches et appliquer des filtres.

Normalisation par les développeurs de l’utilisation des bibliothèques open source

Les entreprises technologiques matures passent du recours opportuniste et occasionnel aux bibliothèques open source à une utilisation plus systématique et planifiée, en suivant les recommandations et meilleures pratiques en vigueur.

Par exemple, les équipes de développement JavaScript s’assurent que les développeurs des différentes équipes utilisent par défaut une seule dépendance pour les requêtes HTTP plutôt que de multiplier les dépendances avec les paquets npm request, axios, node-fetch ou autres. L’idée n’est pas simplement de faciliter la gestion des dépendances open source, mais aussi de centraliser les connaissances et expertises sur l’API, simplifier la résolution des problèmes, etc.

Pour une équipe donnée, êtes-vous sincèrement capable de répondre aux questions suivantes ?

• Quelles bibliothèques open source sont les plus utilisées dans les projets de mon service de R&D ?

• Lesquelles de mes bibliothèques open source sont considérées comme obsolètes ?

• Lesquelles des bibliothèques open source de mes projets sont soumises à des licences copyleft de type GPL-2  ?

• Quelles bibliothèques open source ont été publiées il y a plus de 15 ans sans jamais avoir été mises à jour depuis ? Devez-vous vous en inquiéter ?

Ces informations, et d’autres, sont autant d’avantages dont vous pouvez profiter en créant une nomenclature des logiciels. Snyk indique également de précieuses informations sur la sécurité des paquets open source avec Snyk Open Source :

Pourquoi une SBOM permet-elle de préparer plus rapidement la sécurisation de votre chaîne d’approvisionnement ?

Qu’est-ce que la sécurité de la chaîne d’approvisionnement logicielle ?

Les inquiétudes historiques au sujet de la sécurité des applications au cours du cycle du développement logiciel ne concernent plus que le code des développeurs, mais aussi tous les outils qu’il utilise pour créer ses logiciels. L’IDE utilisé par le développeur pour écrire son code, les composants open source avec lesquels il a créé ses applications, les pipelines de CI/CD et la configuration de l’infrastructure de déploiement forment une surface d’attaque absolument gigantesque. On pourrait aller jusqu’à dire que le risque concerne jusqu’aux puces matérielles de l’ordinateur utilisé pour développer.

À noter que le département du Commerce des États-Unis a publié un document faisant suite au décret présidentiel 14028 relatif à l’amélioration de la cybersécurité de la nation, dans lequel il cite les éléments minimums devant être inclus dans une nomenclature des logiciels. Étudions plus en détail la chaîne d’approvisionnement et essayons de tirer quelques enseignements de cette analyse.

La chaîne d’approvisionnement logicielle correspond à l’ensemble des composants faisant partie du workflow de développement d’un logiciel. Dans un premier temps, on pourrait penser que cette chaîne englobe simplement les dépendances que vous ajoutez à vos projets. Certes, elle les inclut. Mais elle va bien plus loin.

Votre IDE est lui aussi un maillon essentiel de votre workflow de développement, non ? Quel risque courrait votre entreprise si votre IDE préféré contenait des portes dérobées ou un malware ? Et si les extensions ou plugins de votre IDE présentaient des vulnérabilités graves ou directement du code malveillant ?

Vulnérabilités dans les extensions VS Code

Le risque posé par les extensions VS Code n’est pas seulement théorique. En mai 2021, Snyk a découvert des vulnérabilités de la sécurité de la chaîne d’approvisionnement dans des extensions Visual Studio Code de la place de marché dédiée qui, d’après leur nombre de téléchargements, touchent plus de 2 millions de développeurs.

Ces extensions, comme Open in Default Browser (520 000 téléchargements) ou Instant Markdown (120 000 téléchargements), constituent une vraie menace pour les développeurs. Si un attaquant parvient à faire cliquer un développeur sur un lien, il pourrait introduire une vulnérabilité Path traversal donnant accès à des fichiers et informations sensibles de l’environnement de développement. Dans les cas les plus graves, un simple clic des développeurs permet aux attaquants d’exécuter une commande à distance.

La vidéo suivante montre pourquoi la sécurité des logiciels de la chaîne d’approvisionnement est cruciale pour les développeurs. Elle présente une exploitation de l’extension de VS Code Instant Markdown et montre comment elle permet de dérober à un développeur des clés SSH sensibles :

Failles de sécurité touchant l’IDE Java

Si vous pensez que la sécurité de la chaîne d’approvisionnement a des conséquences désastreuses sur l’écosystème JavaScript, jetez un œil à la chronologie établie par l’ENISA de 24 incidents de sécurité de la chaîne d’approvisionnement survenus en seulement 18 mois (de janvier 2020 à juillet 2021). Certains d’entre eux ont touché des développeurs Java par le biais de l’IDE NetBeans :

Sécurisation des logiciels open source utilisés par les développeurs

Mais alors, comment limiter les inquiétudes liées à la chaîne d’approvisionnement logicielle sur l’ensemble du cycle du développement logiciel ? La tenue d’une nomenclature des logiciels à jour constitue un bon début, mais c’est aussi une obligation imposée par décret du président des États-Unis en raison des menaces que posent les composants logiciels open source aux entreprises comme aux administrations.

La sécurité de la chaîne d’approvisionnement open source dépend non seulement des menaces provenant des vulnérabilités connues et exploitations zero-day, mais aussi de la sécurité globale des paquets. Des signaux comme la fréquence des commits et nouvelles versions, le nombre de tickets ouverts et la communauté globale de contributeurs au projet participent au score global de sécurité du paquet. Vous devez les utiliser pour évaluer la gestion globale du projet et le risque qu’il soit victime d’activités malveillantes.

Snyk a créé Snyk Advisor précisément pour répondre à ces questions en lien avec la sécurité des paquets de la chaîne d’approvisionnement logicielle open source. Il prend actuellement en charge les métadonnées d’écosystèmes comme JavaScript, Go, Python et les images de conteneurs Docker. Nous vous recommandons vivement de l’utiliser lors de votre recherche de bibliothèques open source.

Génération d’une nomenclature des logiciels open source avec Snyk

Snyk Open Source utilise les fichiers de manifeste et lockfile des paquets pour créer un graphique complet des dépendances. Il s’agit d’un outil très utile pour repérer les vulnérabilités dans la hiérarchie ou d’autres problèmes, comme les paquets obsolètes. Toutefois, un tel graphique ne constitue pas à proprement parler une nomenclature des logiciels.

Gareth Rushgrove, vice-président des produits chez Snyk, s’est penché sur les possibilités d’évolution des normes SBOM rendues possibles avec Snyk et SPDX. Dans cet article, il explique que Snyk étudie différentes utilisations possibles des outils communautaires et présente snyk2spdx, un projet open source qui convertit la sortie de la CLI Snyk au format SPDX.

Si vous aimez particulièrement l’API Snyk, il révèle également comment l’utiliser pour récupérer le fichier de manifeste d’un paquet et les détails des vulnérabilités sous forme de source de consommation, que vous pouvez ensuite convertir au format SPDX.

Pour résumer, il est important aujourd’hui d’imposer la création de nomenclatures des logiciels dans le développement et le processus de livraison en raison des inquiétudes pesant sur la chaîne d’approvisionnement. Cette ressource permet de répondre à de nombreuses questions, que ce soit en matière d’inventaire, d’intégrité ou d’origine.

Nous vous recommandons vivement de lire les articles suivants pour en savoir plus sur la sécurité de la chaîne d’approvisionnement open source et la nomenclature des logiciels :

• Understanding the software supply chain security requirements in the cybersecurity Executive Order par Daniel Berman

• Licences open source : types et comparaison pour une comparaison détaillée des différentes licences

• Managing license compliance across your organization with Snyk’s license policies par Josepha Riveros

• La documentation Snyk pour découvrir un exemple pratique de gestion des politiques de licence sur la plateforme Snyk