Anticiper les vulnérabilités grâce aux correctifs de sécurité

Traditionnellement, dans le cadre du processus de développement logiciel, les équipes publient généralement de nouvelles versions de leurs packages ou applications pour corriger les problèmes de sécurité au fur et à mesure qu’ils surviennent.

Dans les projets open source, toutefois, les responsables de maintenance sont généralement des bénévoles et peuvent être accaparés par leurs obligations habituelles. La publication de versions correctives des packages peut donc prendre du temps. Un écart important peut alors se creuser entre la découverte d’une vulnérabilité et sa correction, puis sa divulgation publique. Or, sans version officielle du composant logiciel intégrant un correctif, le risque d’exploitation augmente.

Pour faire face à ce type de situation, Snyk sélectionne des correctifs de sécurité pour les projets JavaScript open source de l’écosystème npm. Nous aidons ainsi les responsables de maintenance à sécuriser leurs packages et à garder une longueur d’avance sur les menaces, même lorsqu’ils ne peuvent pas corriger immédiatement les problèmes de sécurité. En coordination avec le responsable de maintenance, Snyk applique un correctif directement à tout package npm concerné. Ainsi, même si aucune version officielle ne résout le problème (ou si la mise à jour risque de faire échouer votre build), Snyk vous protège.

Pourquoi les correctifs de sécurité sont-ils importants ?

Le délai avant la publication d’un correctif de sécurité par les responsables de maintenance open source peut avoir de graves conséquences. C’est pourquoi les correctifs de sécurité sont essentiels. Les vulnérabilités de pollution de prototype récemment découvertes dans la célèbre bibliothèque JavaScript lodash en sont un bon exemple.

L’équipe de recherche en sécurité de Snyk a découvert des vulnérabilités de pollution de prototype dans lodash (CVE-2019-10744), qui affectaient toutes les versions. Dès leur découverte, nous avons collaboré avec John Dalton, le responsable de maintenance de lodash, dans le cadre d’une procédure de divulgation responsable afin de lui communiquer nos conclusions et de fournir des correctifs de sécurité.

Une fois les correctifs rendus publics sous la forme d’une Pull Request visant à corriger le problème de sécurité dans le dépôt lodash, le compte à rebours avant la publication d’une version officielle de lodash intégrant ces correctifs a commencé.

Les informations sur la vulnérabilité ont été rendues publiques le 2 juillet 2019, mais la version officielle a tardé une semaine et n’a été publiée que le 9 juillet 2019.

Le correctif de sécurité fourni par le mécanisme de Snyk est gratuit pour tous les utilisateurs. Nous ouvrons proactivement des Pull Requests pour appliquer le correctif, remédier à la vulnérabilité et protéger vos projets.

Comment Snyk applique-t-il les correctifs de sécurité ?

Le mécanisme de correction des modules de Snyk s’intègre à la prise en charge des scripts npm package.json pour les événements de cycle de vie. Le processus npm permet aux programmes de remédiation de s’intégrer facilement à la gestion du cycle de vie npm aux différentes étapes de votre build, par exemple lors de l’installation de npm ou de la publication dans un registre.

La page de documentation npm fournit des informations détaillées sur tous les événements de cycle de vie npm disponibles, ainsi que sur leur fonctionnement et le moment où ils se déclenchent.

Snyk utilise l’événement de cycle de vie prepublish dans package.json pour appliquer des correctifs avant que le package soit empaqueté et publié, ainsi que chaque fois que npm install est exécuté localement sans argument supplémentaire_._Pour mieux comprendre le fonctionnement, créons quelques packages en local et utilisons verdaccio comme registre npm local pour expérimenter la publication et l’installation de modules.

Après avoir exécuté npm init -y et mis à jour notre module de test aaa pour y inclure un script prepublish, le code ressemble à ceci :

1
2{
3  "name": "aaa",
4  "version": "1.1.0",
5  "description": "",
6  "scripts": {
7    "test": "echo \"Error: no test specified\" && exit 1",
8    "prepublish": "echo hello little green world"
9  },
10  "main": "index.js",
11  "keywords": [],
12  "author": "",
13  "license": "ISC"
14}

Lorsque nous exécutons npm install dans l’invite de commande, le résultat suivant s’affiche :

Notre événement de cycle de vie npm a été exécuté : ce court texte s’affiche dans la console et Snyk applique également les correctifs nécessaires.

Snyk modifie la configuration de votre événement pre-publish comme suit :

1
2"scripts": {
3  "snyk-protect": "snyk protect",
4  "prepublish": "npm run snyk-protect"
5}

Lorsqu’un npm install est exécuté, Snyk détecte les vulnérabilités présentes dans votre code, télécharge depuis notre base de données un correctif pour les résoudre et l’applique au module vulnérable dans le dossier node_modules.

Ainsi, lorsque vous clonez un projet, en installez toutes les dépendances et l’exécutez, Snyk est appelé pendant l’installation des modules pour corriger la vulnérabilité.

Pour les projets Node.js, votre application est déjà protégée lorsque vous l’exécutez. Pour une bibliothèque JavaScript classique qui transpile le code, par exemple à l’aide d’un outil comme webpack, babel ou typescript, le résultat du bundle, souvent présent dans dist/, intègre également le correctif de sécurité.

Comment fonctionne npm prepublish ?

Vous suivez peut-être des processus différents, et pas seulement un simple npm install pour votre projet. Vous pourriez donc ignorer l’événement prepublish. Dans ce cas, les correctifs Snyk ne sont pas appliqués.

Pour mieux comprendre l’événement de script npmprepublish, examinons comment il est déclenché :

• npm install

• npm install --dev

• npm ci

• yarn

• yarn install

• yarn install --frozen-lockfile

Quand l’événement npm prepublish n’est-il pas déclenché ?

• npm install --prod

• yarn install --prod

Comme indiqué précédemment, lorsque vous exécutez npm install avec des arguments supplémentaires, prepublish n’est pas inclus. Par conséquent, si votre processus d’installation des dépendances d’un module npm comprend l’exécution de npm install --prod, vous pouvez appeler directement snyk protect à la place.

Prenons par exemple la configuration Travis CI suivante :

1
2install:
3  - npm install --prod
4  - snyk protect

Correctifs de sécurité Snyk pour les bibliothèques

Dans nos tests de packages npm, nous avons utilisé ces deux bibliothèques :

• aaa : cette bibliothèque présente des vulnérabilités dans ses dépendances, et ses responsables de maintenance n’ont publié aucune nouvelle version avec un correctif officiel. Les correctifs Snyk corrigent ces vulnérabilités.

• bbb : cette bibliothèque utilise aaa comme dépendance.

Dans notre cas, le projet bbb utilise aaa. Lorsque bbb installe ses dépendances, par exemple en exécutant npm install, l’événement de cycle de vie prepublish de aaa ne se déclenche pas.

Cela signifie que, sauf si aaa a été publié dans le registre sous forme de bundle transpilé intégrant toutes ses dépendances — une pratique courante uniquement pour les bibliothèques frontend —, l’installation de aaa dans bbb laisse les bibliothèques imbriquées de aaa exposées aux mêmes vulnérabilités connues.

Dans ce cas, le responsable de maintenance de la bibliothèque parente bbb doit remédier aux vulnérabilités en proposant des correctifs qui résoudront également celles des dépendances imbriquées de aaa.

En résumé

En conclusion, lorsque les responsables de maintenance ne peuvent pas publier assez rapidement de nouvelles versions intégrant des correctifs de sécurité — ou, pire, qu’ils ont quitté le projet et ne répondent plus —, le risque que des vulnérabilités persistent augmente. C’est pourquoi les correctifs de sécurité ciblés sont essentiels pour vous aider à garder une longueur d’avance sur les vulnérabilités non corrigées.