L’open source est partout, c’est l’un des moteurs de l’innovation logicielle du monde académique au monde de l’entreprise (75% des bases de code auditées par Synopsys dans le rapport OSSRA 2021 reposent sur des composants open source). Sa prévalence dans les logiciels commerciaux atteint des niveaux sans précédent, dans la mesure où la Commission européenne l’a récemment identifié comme un bien public dans une étude récente évaluant son impact sur l’économie de la région.
Mais la nature interstitielle de l’open source dans les logiciels modernes en fait également un sujet de préoccupation en matière de sécurité et de conformité, car elle est capable d’exposer les organisations qui l’utilisent à une multitude de risques et de vulnérabilités inconnus. La plupart des discussions que nous entendons aujourd’hui sur la sécurité dans cet espace sont axées sur l’identification, la correction et la correction des vulnérabilités, toutes vues du point de vue du « consommateur ».
Cette fois, nous avons décidé d’aller de l’autre côté de la clôture. Nous avons eu le plaisir d’échanger quelques mots avec Bryan Van de Ven, co-créateur et mainteneur principal du projet Bokeh, une bibliothèque Python pour la visualisation de données. Bryan nous a donné un aperçu de la façon dont les mainteneurs open source comme lui protègent leurs projets contre les tentatives d’acteurs malveillants essayant d’exploiter les failles de sécurité. L’objectif des attaquants est simple : introduire des vulnérabilités en aval et, à son tour, attaquer les chaînes d’approvisionnement logicielles qui dépendent des mêmes packages et bibliothèques open source.
Bokeh, la bibliothèque de visualisation interactive pour le navigateur moderne
Bokeh est une bibliothèque de visualisation interactive pour les navigateurs Web modernes, écrite en Python. Il permet une construction élégante et concise des tracés tout en maintenant une interactivité haute performance sur de grands ensembles de données. Bokeh peut aider quiconque souhaite créer rapidement et facilement des tracés, des tableaux de bord et des applications de données interactifs.
Avant de commencer son entreprise avec Bokeh en 2012, Bryan n’était pas étranger aux bibliothèques open source. Il est l’auteur du gestionnaire de packages conda et a travaillé à temps plein chez Anaconda sur sa distribution, simplifiant la gestion et le déploiement des packages pour plus de 25 millions d’utilisateurs dans le monde. Inspiré par sa précédente contribution à Chaco (bibliothèque de visualisation de données Python) et l’essor des frameworks JavaScript pour le frontend au début des années 2010, Bryan s’est associé à Peter Wang pour offrir une alternative aux développeurs Python, qui travaillaient sur des applications de données interactives pour le navigateur moderne. Le reste appartient à l’histoire.
Pourquoi la sécurité est-elle importante pour les projets open source comme Bokeh ?
Avec plus de 37 000 référentiels publics GitHub déclarant son utilisation et 2,5 millions de téléchargements mensuels, Bokeh s’est fait un nom. Bryan pense que cela a beaucoup à voir avec les premiers jours du projet, où la patience, la réactivité et la réceptivité aux contributions d’une communauté à ses stades embryonnaires jouent un rôle déterminant dans les succès ultérieurs.
Vient maintenant la partie difficile, s’assurer que Bokeh est un code open source sur lequel les développeurs individuels et les équipes d’entreprise peuvent s’appuyer en toute sécurité. Ensemble, nous avons discuté de certaines des menaces qui empêchent les mainteneurs open source de dormir la nuit :
Typosquattage
Cette attaque implique des acteurs malveillants poussant des packages malveillants portant des noms similaires à l’original vers un registre de confiance et croisant les doigts pour que les utilisateurs tombent dans leur sale tour. Les packages hébergés sur les registres npm et PyPI ont été des cibles notables, nous rappelant que les développeurs peuvent également être la proie d’une autre race de Hameçonnage.
Avec plus de 2,5 millions de téléchargements mensuels partagés entre conda et pip et environ 150 millions de demandes de ressources BokehJS sur cdn.bokeh.org chaque année, la bibliothèque bokeh semble être prête à être choisie, du moins du point de vue d’un attaquant.
Une fois les packages malveillants installés et exécutés au runtime, les attaquants peuvent :
- Siphonner les variables d’environnement pour un mouvement latéral supplémentaire (attaque crossenv)
- Détourner des ressources de cloud computing pour le crypto-mining (attaques PyPI en 2021)
Malheureusement, les mainteneurs de paquets ne peuvent pas faire grand-chose ici. Il est recommandé aux utilisateurs de scanner leurs dépendances de projet pour vérifier leur intégrité avec des outils tels que WhiteSource, Sonatype, Snyk ou Vdoo.
Pipelines de construction et de déploiement compromis
Comme les autres développeurs, les principaux responsables de la maintenance peuvent ne pas être des experts en sécurité des applications. Ils ne sont pas particulièrement à l’abri d’introduire des bogues dans leur code ou de commettre par inadvertance des secrets dans le référentiel git de leur projet.
Une gestion non sécurisée des informations d’identification peut conduire à leur diffusion publique sur GitHub, avec des conséquences pour des projets comme Bokeh allant du Cloud Jacking (par exemple, l’abus des ressources de cloud computing AWS) à la compromission de leurs droits de publication sur PyPI ou Anaconda.
Avec une équipe de cinq à six mainteneurs principaux et un nombre total d’environ 500 contributeurs couvrant la vie du projet, les choses peuvent devenir compliquées pour Bokeh si les informations d’identification sont divulguées. Bryan nous assure que seule une poignée de contributeurs est habilitée à gérer les secrets du projet et que l’équipe utilise les secrets cryptés de GitHub pour stocker et récupérer les informations d’identification dans leurs pipelines GitHub Actions CI.
En plus de cette mesure, Bokeh renforce les pipelines CI avec GitGuardian, capturant efficacement tous les secrets divulgués dès que le code qui les enveloppe atteint les étapes de construction. Plus à ce sujet plus tard.
Menaces sur l’intégrité des actifs
Les logiciels open source ne sont pas seulement un référentiel de code public hébergé sur GitHub. C’est aussi un ensemble d’atouts, guidant à la fois les débutants et les membres expérimentés de la communauté tout au long de leur parcours d’apprentissage. Pour n’en citer que quelques-uns de Bokeh :
- Site Internet
- CloudFront CDN pour la distribution du runtime BokehJS sur cdn.bokeh.org
- Documents publics
- Blog (hébergé sur Medium)
- Comptes de réseaux sociaux (YouTube, Twitter…)
- Communauté et soutien (Discours)
- Autres outils (Zapier pour l’automatisation, Pingdom pour les formulaires et sondages)
Contrairement au code open source, de tels services ne s’exécuteront jamais dans les environnements de production des utilisateurs. Mais ils sont tout aussi importants en termes de protection qu’ils méritent puisqu’ils pourraient offrir des ouvertures aux attaquants ayant un goût prononcé pour les tactiques d’ingénierie sociale.
Pour tout autre que la documentation, Bokeh utilise les offres de niveau gratuit 1Password aux projets open source pour stocker et gérer en toute sécurité toutes leurs informations d’identification.
Comment GitGuardian protège-t-il les dépôts publics de Bokeh ?
Bryan nous dit que sa première rencontre avec des informations d’identification renversées était dans un café, une coïncidence ? Lors du test de nouvelles fonctions d’automatisation et du téléchargement de la documentation sur le CDN CloudFront, il a accidentellement poussé une clé secrète AWS et son jeton.
Heureusement, GitGuardian avait le dos. Notre service bénévole a détecté ce secret dans le référentiel public de bokeh et lui a envoyé une alerte en temps opportun avec les détails de l’incident.
Bryan a pu y remédier à temps, en révoquant et en faisant pivoter son secret, et enfin en réécrivant l’historique de git pour supprimer toutes les preuves de la fuite. En moins d’une heure, sa réponse rapide lui a permis d’annuler les dégâts et de fermer la fenêtre pour tout exploit.
Depuis cet incident, son équipe a exécuté l’interface de ligne de commande de GitGuardian, gg-shield, sur chaque demande d’extraction, dans leurs workflows GitHub Actions. Les vérifications de l’analyse secrète et leurs résultats sont également affichés dans le VCS, garantissant que tous les contributeurs ont une visibilité complète et égale – sans jamais quitter leurs environnements de développement.