Outils DevSecOps pour les projets open source en JavaScript et Node.js

Dans cet article, je vous propose des bonnes pratiques et explique comment les responsables de maintenance et les développeurs peuvent adopter des outils DevSecOps pour les projets open source afin d’améliorer leur niveau de sécurité.

Les incidents de sécurité et les histoires effrayantes liées aux packages malveillants dans l’écosystème open source JavaScript ne manquent pas. En tant que membres de l’écosystème open source, que nous maintenions ou utilisions des projets, nous devons accorder toute l’attention nécessaire à la sécurité de l’open source afin de ne pas nous exposer tous à des risques.

La sélection suivante d’outils DevSecOps et de pratiques de sécurité s’appuie sur mon expérience chez Snyk, où j’ai travaillé en étroite collaboration avec le projet verdaccio, un proxy privé npm léger et un registre. Nous allons notamment aborder les points suivants :

1. Adoptez une politique de divulgation responsable des vulnérabilités et intégrez-la à vos projets dans le cadre de vos consignes de sécurité.

2. Mettez en place un processus et des consignes de sécurité.

3. Assurez-vous que tous les responsables de maintenance et collaborateurs ont activé l’authentification à deux facteurs (2FA) pour GitHub et le registre npm.

4. Évitez les fuites de données et l’exposition d’informations sensibles en utilisant des hooks Git pre-commit, qui empêchent les développeurs de divulguer des mots de passe et des secrets lors de leurs commits et push vers un dépôt.

5. Intégrez l’analyse et la correction des dépendances open source afin d’éviter les vulnérabilités dans les packages open source tiers. L’intégration de Snyk au workflow Git peut vous aider.

6. Utilisez Snyk Advisor pour rechercher et comparer plus d’un million de packages open source dans le registre npm et choisir le bon package npm.

Adoptez une politique de divulgation responsable des vulnérabilités

Une politique de divulgation responsable permet aux chercheurs en sécurité et aux autres utilisateurs de signaler une vulnérabilité affectant le projet et de gérer le processus dans le cadre d’une discussion privée, à l’abri des regards indiscrets.

Cette discussion privée permet ensuite aux parties concernées, à savoir le responsable de maintenance et le chercheur en sécurité, d’enquêter plus en détail, de trier la vulnérabilité, de produire une preuve de concept, puis de préparer un correctif pour y remédier.

Lorsqu’un correctif est disponible et qu’il a été publié depuis une durée raisonnable, la vulnérabilité peut être divulguée publiquement et les utilisateurs peuvent effectuer une mise à niveau pour bénéficier du correctif de sécurité.

Ce processus contribue à protéger les utilisateurs contre les vulnérabilités qui seraient divulguées sans coordination préalable avec le projet.

Pour en savoir plus sur l’importance de la divulgation responsable des vulnérabilités, consultez Comprendre la divulgation responsable. L’équipe de recherche en sécurité de Snyk propose un programme destiné aux responsables de maintenance de projets open source. Notre équipe collabore au tri des vulnérabilités, à l’élaboration d’un correctif et à la demande d’un CVE. Ce programme est disponible pour de nombreux écosystèmes de langages, tels que Node.js, Java, .NET, Python, Ruby, PHP et d’autres :/.

Établissez des consignes de sécurité

Un projet doit disposer de processus de sécurité pour gérer les réponses aux incidents au sein de l’équipe et communiquer son niveau de préparation et ses règles de sécurité aux chercheurs en sécurité.

Les informations suivantes doivent être accessibles :

1. Les politiques de sécurité du projet, par exemple les vulnérabilités considérées comme des problèmes de sécurité et celles qui n’en constituent pas.

2. Une politique de divulgation responsable des vulnérabilités ou des références à des programmes existants qui prennent cela en charge.

3. Les coordonnées permettant de contacter les responsables de la sécurité du projet. Il est conseillé d’adopter les champs pertinents de la spécification security.txt.

4. Évitez les fuites de secrets : que vous utilisiez des clés API, des mots de passe ou d’autres secrets, ils peuvent très facilement se retrouver dans le contrôle de code source ou même dans un package publié sur le registre public npm.

Pour communiquer efficacement ces informations, il est conseillé de les fournir dans un fichier SECURITY.md placé à la racine du projet.

Tous les collaborateurs du projet doivent activer la 2FA

En tant que responsables de maintenance et collaborateurs de confiance, chargés de publier des versions de votre projet exemptes de logiciels malveillants, nous devons veiller à ce que nos comptes ne soient pas compromis. Cela s’est déjà produit sur npm, notamment lors de l’incident de sécurité eslint-scope, avec le package npm mailparser et d’autres encore.

Oui, des packages ont déjà été compromis et des logiciels malveillants y ont été injectés ; cela se reproduira. Vous pouvez en apprendre davantage sur les portes dérobées et découvrir à quel point il est facile d’en créer une avec Node.js et de la publier sur npm.

Pour réduire le risque de prise de contrôle d’un compte et de compromission d’un package, veillez à ce que :

1. Tous les collaborateurs activent l’authentification à deux facteurs (ou une autre forme d’authentification multifacteur) pour accéder au dépôt de code source.

2. Tous les collaborateurs autorisés à publier le package activent l’authentification à deux facteurs sur le registre npm.

3. N’oubliez pas de tester vos projets pour détecter les portes dérobées connues !

Évitez les fuites de données et l’exposition d’informations sensibles

Un problème courant dans la gestion des dépôts publics de projets open source est qu’il est beaucoup trop facile de publier par erreur des secrets, comme des mots de passe ou des clés API, ou d’autres informations sensibles.

J’ai vu cela se produire à plusieurs reprises, aussi bien dans des projets open source que dans des projets privés en source interne, qui ne sont pas à l’abri des conséquences d’une fuite de secrets. N’oubliez pas : Git se souvient de tout !

Utiliser des hooks Git

Votre répertoire de travail peut contenir des secrets dans des fichiers dédiés, comme un fichier .env, qui doivent être ignorés lors de leur commit dans un système de gestion de code source ou de leur publication dans un registre de packages. Des erreurs peuvent toutefois survenir : nous devons donc mettre en place des contrôles pour nous en prémunir.

Il existe de nombreux outils très utiles capables d’analyser statiquement vos commits à l’aide d’un hook Git pre-commit afin de vérifier que vous ne tentez pas d’envoyer des mots de passe ou des informations sensibles dans votre dépôt GitHub. Les commits sont rejetés si l’outil détecte une expression régulière configurée pour repérer des informations sensibles. Cela peut ralentir légèrement les push, mais le jeu en vaut la chandelle.

Vous pouvez également utiliser de tels outils dans vos pipelines CI/CD, par exemple GitGuardian, pour interrompre automatiquement les builds lorsque des informations sensibles sont trouvées dans le code ou dans un fichier de configuration. Des règles communes à toute l’équipe pour éviter ces incidents constituent un excellent moyen d’encadrer les pratiques dans le workflow de développement existant.

Pourquoi est-ce important ?

1. https://github.blog/2019-05-14-git-ransom-campaign-incident-report/

2. https://about.gitlab.com/2019/05/14/git-ransom-campaign-incident-report-atlassian-bitbucket-github-gitlab/

Éviter les fuites de mots de passe : l’outil detect-secrets

Il est essentiel, pour la sécurité, de veiller à ce que les responsables de maintenance et les développeurs du projet open source Verdaccio, un registre npm, ne divulguent pas de mots de passe ni d’informations sensibles. Ce projet fournit un registre privé npm et un serveur proxy.

Je les ai rejoints pour collaborer à une pull request visant à ajouter un outil à leur workflow de développement afin de les protéger contre la fuite d’informations sensibles dans le contrôle de code source.

Le choix du projet detect-secrets de Yelp s’explique par sa flexibilité pour gérer un manifeste des secrets présents dans un dépôt et par son architecture générale d’audit des secrets détectés. Il permet de gérer hors ligne les manifestes de secrets afin de les suivre et de les ajouter à une liste d’autorisation, tout en appliquant des mesures préventives lors des interactions des utilisateurs avec le dépôt Git.

Modes de fonctionnement :

1. Mesure préventive : pour empêcher les utilisateurs d’introduire des secrets dans le code source, le projet fournit un exécutable detect-secrets-hook qui reçoit des fichiers en arguments et les analyse pour y détecter des secrets. S’il en trouve, il affiche une alerte et interrompt complètement le processus.

2. Analyse hors ligne pour l’audit et la mise sur liste d’autorisation : la mesure préventive décrite ci-dessus ne s’applique qu’à la création des commits et empêche donc uniquement l’ajout de secrets à partir du moment où elle est mise en place. Une analyse hors ligne permet de parcourir tous les fichiers d’un dépôt Git pour créer une base de référence des secrets connus. On peut ensuite vérifier si ces détections sont des faux positifs ou s’il s’agit de secrets à supprimer et à révoquer correctement.

Ces deux modes de fonctionnement sont complémentaires et permettent aux développeurs de choisir librement l’un ou l’autre, selon leurs besoins.

Utiliser detect-secrets dans vos hooks Git ne convient pas forcément à tous les projets, notamment à ceux qui utilisent JavaScript et Node.js, car l’outil nécessite un environnement Python fonctionnel. Si cela ne pose pas de problème à votre projet, vous pouvez l’installer et commencer à l’utiliser comme suit :

$ pip install --user detect-secrets

Vous pouvez également suivre cette méthode pour les projets JavaScript et Node.js basés sur npm et prévenir l’exposition d’informations sensibles avec detect-secrets.

Pour mettre en place une mesure préventive pre-commit destinée aux développeurs JavaScript, nous allons nous appuyer sur les deux dépendances de projet suivantes :

• husky permet aux projets npm de gérer facilement les hooks Git des développeurs grâce à un manifeste au niveau du projet et à une dépendance npm qui simplifie la gestion des hooks pour les développeurs JavaScript avec des outils qu’ils connaissent.

• lint-staged permet d’exécuter des tâches, comme des linters et des formateurs, sur les fichiers indexés afin de les mettre en conformité avec les règles préconfigurées lors de leur commit dans le contrôle de code source.

Remarque : lint-staged est facultatif, mais constitue une dépendance très courante dans les projets JavaScript.

Une fois lint-staged et husky ajoutés aux dépendances de développement du projet, vous pouvez mettre à jour le fichier package.json du projet avec la configuration requise pour le hook pre-commit :

"husky": {
   "hooks": {
     "pre-commit": "lint-staged"
   }
 },
 "lint-staged": {
   "linters": {
     "**/*.js": [
       "detect-secrets-hook --baseline .secrets-baseline"
     ]
   }
 }

Dès lors, chaque fichier ajouté ou modifié dans le contrôle de code source Git sera analysé afin de détecter les informations sensibles, comme les secrets, les mots de passe et les clés API, et l’opération de commit dans le dépôt sera interrompue.

Remarque : dans les monorepos où les dépendances husky et lint-staged sont installées dans des répertoires imbriqués plutôt qu’à la racine, le répertoire .git/ nécessite une mise à jour de la configuration lint-staged pour prendre ce cas en charge :

 "lint-staged": {
   "relative": true,
   "linters": {
     "**/*.js": [
       "detect-secrets-hook --baseline .secrets-baseline"
     ]
   }
 }

Référence de base des secrets

Pour vérifier que tous les fichiers du dépôt Git ont été analysés afin d’y détecter d’éventuels secrets, nous lançons une analyse ponctuelle :

detect-secrets scan > .secrets-baseline

Une fois l’analyse terminée, le résultat généré sert de référence pour les secrets autorisés dans l’ensemble du code source. Les résultats JSON comprennent les métadonnées de tous les plugins utilisés, la date de génération de l’analyse, un hachage du secret et les informations sur le fichier dans lequel il a été trouvé.

Il arrive que des chaînes ressemblant à des secrets figurent dans la documentation, par exemple dans des fichiers README. Elles doivent alors être commités et conservées dans le contrôle de code source, puisqu’il ne s’agit pas de vrais secrets. Dans d’autres cas, il s’agit bien de secrets qui doivent être traités de manière sécurisée. Une fois le problème résolu, une nouvelle action scan génère une nouvelle référence sans les secrets supprimés.

Pour aider les équipes à corriger les secrets trouvés dans leur base de code, l’outil propose une fonctionnalité d’audit qui parcourt le fichier de référence et demande à l’utilisateur de choisir de manière interactive si un secret est un faux positif, par exemple s’il est utilisé dans des fichiers de test, ou un vrai positif, auquel cas il est déjà présent dans le contrôle de code source et doit être supprimé.

Intégrez Snyk pour développer rapidement tout en restant en sécurité

Comment développer rapidement tout en restant en sécurité ?

Les responsables de maintenance et les collaborateurs de projets open source finissent souvent par intégrer des packages open source à leurs projets. Ils continuent ensuite à ajouter des dépendances au fil du temps. Comment savoir si la prochaine dépendance que vous ajouterez est vulnérable ?

L’équipe Verdaccio a créé une intégration Git qui intègre Snyk à son dépôt GitHub, pour mettre en place un workflow Git entièrement pris en charge et proposer des tests de sécurité dans l’interface en ligne de commande.

Vous souhaitez démarrer rapidement avec Snyk ? Consultez ce guide pour passer de novice à champion de la sécurité. Mieux encore, regardez cette vidéo de 1 min 35 pour vous lancer rapidement avec Snyk :

Play Video: Getting Started with Snyk: Import and Test a GitHub Repository

Utilisez Snyk Advisor pour choisir le bon package

Le projet npm Verdaccio utilise des dépendances comme commander, mais en tant que développeur, comment savoir si le package npm commander est un projet fiable ?

Heureusement, Snyk Advisor vous permet de rechercher et de comparer plus d’un million de packages open source, et d’évaluer des critères de décision clés comme la maintenance, la popularité, la communauté et la posture de sécurité du projet. À partir de ces informations, Snyk Advisor calcule un indicateur de santé globale du package.

Verdaccio dépend également de cookies et de cors. Quels scores obtiennent-ils ? Je vous laisse le découvrir !

Pour conclure

En résumé, nous avons passé en revue plusieurs outils et pratiques DevSecOps que vous pouvez utiliser en tant que responsable ou développeur d’un projet open source. Qu’il s’agisse d’empêcher la fuite de mots de passe dans le contrôle de version, de tester et de surveiller vos dépendances pour détecter les vulnérabilités, ou encore de choisir le bon package npm avec Snyk Advisor.

Je vous recommande de poursuivre votre lecture avec :

• Le hub DevSecOps pour découvrir les pratiques de sécurité adoptées par d’autres organisations, comme Auth0 et Datadog. Vous y trouverez également des analyses approfondies de pratiques de sécurité comme la modélisation des menaces.

• Avec Juan Picado, nous avons rédigé le guide pratique des 10 bonnes pratiques de sécurité npm. Vous pouvez télécharger le PDF ou le lire sur le blog.

• Il y a de fortes chances que vous ayez déjà utilisé des fichiers de verrouillage dans des packages basés sur npm. Saviez-vous que ces fichiers peuvent constituer un angle mort de sécurité et permettre l’injection de modules malveillants ?