Pourquoi les organisations font-elles confiance à Snyk pour remporter la bataille de la sécurité de l’open source ?

Définir et expliquer le rôle d’une équipe de sécurité interne, dédiée à la recherche et à l’analyse des vulnérabilités dans les écosystèmes open source afin d’en assurer la sécurité, n’est pas une tâche facile. Il est difficile de répondre brièvement à une question pourtant assez simple : « Que fait l’équipe de sécurité de Snyk ? » Il n’existe pas de réponse courte pour expliquer précisément nos activités et notre spécialisation.

À mon avis, le problème vient du fait que les titres de « chercheur » et d’« analyste » en général, et de « chercheur en sécurité » ou d’« analyste en sécurité » en particulier, sont parmi les plus galvaudés et les plus utilisés à tort depuis celui de « consultant ». Ils peuvent désigner à peu près n’importe quoi, et chaque entreprise semble avoir une définition entièrement différente du rôle de son équipe de recherche en sécurité (quand elle en a une).

Il est probable que je ne parvienne pas à expliquer pleinement aux personnes que je rencontre en dehors du travail en quoi consiste mon métier. Mais cet article tente au moins de résoudre en partie ce problème en détaillant une bonne fois pour toutes les missions de la formidable équipe de recherche en sécurité de Snyk.

Voici les sujets abordés dans cet article :

• Notre mission

• Nos méthodes

  • Bases de données structurées des communautés de l’écosystème

  • Bases de données non structurées et avis de sécurité

  • Détection de vulnérabilités non publiées

  • Signalements des communautés et du monde universitaire

  • Recherche interne et analyse des tendances en matière de vulnérabilités

• En résumé

Notre mission

La mission de Snyk est de rendre le monde de l’open source plus sûr et de donner aux développeurs les moyens de jouer un rôle actif dans la sécurisation de leurs bases de code. Pour cela, nous analysons notamment les bibliothèques open source gérées et les images de conteneur de nos utilisateurs à la recherche de vulnérabilités. Nous leur fournissons les informations les plus précises et les plus exploitables possible sur les vulnérabilités détectées, ainsi que des solutions pour y remédier.

Au sein de l’entreprise, l’équipe de recherche en sécurité a pour mission de constituer et d’enrichir la base de données des vulnérabilités Snyk Intel, qui alimente nos analyses et fournit ces informations aux utilisateurs afin qu’ils puissent corriger les vulnérabilités avant qu’elles ne deviennent des menaces pour la sécurité.

Créer et maintenir une base de données de sécurité de premier ordre est un travail exigeant. Il nous faut veiller non seulement à l’exactitude des données, mais aussi à l’étendue et à la profondeur de notre base. Le plus simple pour expliquer comment nous procédons est de vous présenter notre méthode de collecte, de vérification et de triage des vulnérabilités.

Nos méthodes

Nous utilisons plusieurs méthodes pour assurer une couverture continue des problèmes de sécurité liés à l’open source :

1. Bases de données structurées des communautés de l’écosystème

Les bases de données gérées par les communautés sont la source de vulnérabilités la plus évidente dans les écosystèmes open source. On peut citer rubysec, friends of php, rustsec et bien d’autres. Elles sont alimentées par des développeurs open source qui travaillent au sein de ces écosystèmes et s’efforcent de donner le plus de visibilité possible aux problèmes de sécurité qui les touchent.

L’équipe de recherche en sécurité de Snyk suit activement ces bases de données communautaires afin de rester au fait des vulnérabilités signalées par les communautés. Malgré l’excellent travail de ces dernières pour informer les utilisateurs des écosystèmes, il reste souvent des vérifications et des analyses à effectuer.

L’équipe de recherche en sécurité vérifie et analyse chaque vulnérabilité signalée afin de :

1. vérifier qu’il s’agit bien d’une vulnérabilité — cela implique d’étudier le problème signalé et, si nécessaire, de créer une preuve de concept pour confirmer que la vulnérabilité est exploitable.

2. rédiger une description complète et précise de la vulnérabilité, en indiquant notamment sa gravité et son score CVSS — en étudiant la vulnérabilité, nous pouvons mieux comprendre ses conséquences et vecteurs d’attaque probables, ainsi que l’utilisation probable du package vulnérable dans l’écosystème. À partir de ces éléments, nous rédigeons une description et un avis de sécurité indiquant le niveau de gravité, afin que les développeurs comprennent au mieux la vulnérabilité et son impact potentiel sur leur base de code.

3. vérifier que les informations concernant les métadonnées importantes, telles que les versions corrigées et les packages affectés, sont complètes et exactes — nous examinons le code du package pour repérer les modifications exactes qui ont introduit la vulnérabilité et celles qui l’ont corrigée. Nous recoupons ensuite ces informations avec le nom et les versions précis du package afin de nous assurer que nous signalons uniquement les packages et versions vulnérables.

4. identifier les fonctions ou classes vulnérables au sein d’un package — lors du triage de la vulnérabilité, nous cherchons à identifier précisément la ou les fonctions vulnérables dans le package. Ces métadonnées permettent aux développeurs de savoir si leur utilisation particulière du package est vulnérable.

5. surveiller et trier les exploits de cette vulnérabilité divulgués dans la nature — même après la publication d’une vulnérabilité, il faut suivre les nouvelles informations qui la concernent, en particulier lorsqu’un exploit abouti est publié. Nous surveillons différentes sources pour repérer les exploits dès leur publication et les évaluons afin d’en déterminer le niveau de maturité. Les développeurs peuvent ainsi savoir comment prioriser la correction de ces vulnérabilités.

2. Bases de données non structurées et avis de sécurité

Les bases de données structurées des écosystèmes sont utiles, mais de nombreuses informations sur les nouvelles vulnérabilités figurent également dans des bases de données non structurées et des avis publics. Il est donc essentiel de surveiller et de trier ces sources.

Les bases de données CVE et NVD en sont l’exemple le plus évident : elles répertorient de nombreuses vulnérabilités dans un format non structuré et non lisible par machine. Au-delà de CVE et NVD, il existe aussi d’innombrables avis de sécurité propres à des produits et listes de diffusion, comme Apache Mailing List, les blogs de mises à jour de Node.JS, les avis de sécurité de Jenkins et bien d’autres, qui nécessitent tous notre attention.

L’équipe doit bien sûr appliquer ici toutes les méthodes décrites dans la section précédente. Il est également nécessaire de structurer les données dans un format lisible par les machines et par les personnes. Par exemple, si la NVD ou Apache Mailing List indique qu’une vulnérabilité touche « Apache Tomcat », les développeurs doivent savoir, parmi les 958 packages liés à « Apache Tomcat » actuellement disponibles dans Maven, si le package précis qu’ils utilisent est vulnérable.

En étudiant en profondeur le code concerné, l’équipe identifie les paramètres du code vulnérable. Elle utilise ensuite ses outils internes pour analyser les packages susceptibles d’être liés à cette vulnérabilité et vérifier s’ils contiennent le code concerné. Nous n’associons la vulnérabilité à un package précis qu’après avoir confirmé la présence et la pertinence du code vulnérable. Ce travail réduit considérablement le nombre de faux positifs dans notre base de données et permet ainsi aux développeurs qui utilisent Snyk de se concentrer sur la correction des vulnérabilités, plutôt que de perdre du temps avec des alertes inutiles.

3. Détection de vulnérabilités non publiées

Jusqu’ici, j’ai surtout expliqué comment l’équipe contribue au triage des vulnérabilités connues et rend les informations les concernant plus exploitables par les développeurs, ce qui est évidemment essentiel. Mais l’équipe a aussi pour rôle de renforcer la sécurité des écosystèmes open source en identifiant des vulnérabilités qui n’ont pas encore été divulguées.

Avec notre équipe Data, nous avons développé plusieurs algorithmes de machine learning pour détecter ce que nous appelons des vulnérabilités « de demi-journée ». Il s’agit de vulnérabilités dont on parle parfois sur des forums publics, mais qui n’ont pas encore été officiellement divulguées.

On sait que ces vulnérabilités sont souvent les plus dangereuses : le délai entre le moment où l’on commence à en parler et celui où elles sont reconnues, permettant au grand public de prendre des mesures correctives, constitue une fenêtre pendant laquelle des acteurs malveillants peuvent tirer parti de leur connaissance précoce de la vulnérabilité.

Nous contribuons à réduire cet écart et pouvons détecter de nouvelles vulnérabilités et en informer les utilisateurs très tôt dans leur cycle de vie. Pour cela, nous surveillons les espaces où l’on discute souvent, à un stade préliminaire, des correctifs de code, des signalements de bugs et des vulnérabilités potentielles : les PR et Issues des systèmes de gestion de code source, les tickets JIRA ou encore des sites comme Reddit et StackOverflow.

Grâce à notre base de données existante, soigneusement constituée à la main, qui rassemble des extraits de code vulnérable, des rapports de bugs et des descriptions de vulnérabilités, nous disposons de nombreuses ressources sur lesquelles fonder nos algorithmes. Nos systèmes peuvent ainsi traiter des milliers d’événements pour tous les packages de nos écosystèmes pris en charge et signaler les vulnérabilités potentielles à l’équipe. Au final, nous pensons avoir mis en place le flux d’alertes à la portée la plus large qui soit.

Ces alertes sont transmises au système d’alerte précoce de l’équipe, qui les trie ensuite. Un analyste examine les informations de l’alerte et, si nécessaire, nous vérifions la vulnérabilité à l’aide d’une preuve de concept avant de contacter les responsables du package pour recueillir leur avis sur la vulnérabilité potentielle.

Après avoir échangé avec les responsables et vérifié la vulnérabilité, nous la publions dans notre base de données afin d’informer l’ensemble de l’écosystème du problème de sécurité et de permettre aux utilisateurs d’y remédier. L’année dernière, nous avons ainsi contribué à divulguer environ 200 vulnérabilités, notamment l’injection de commandes dans Vizion et l’attaque par temporisation touchant les packages populaires Escada et Elliptic.

4. Signalements des communautés et du monde universitaire

La divulgation responsable des vulnérabilités est un modèle courant dans le domaine de la cybersécurité. Les vulnérabilités zero-day sont d’abord signalées de manière privée, afin de laisser aux responsables du code et des applications suffisamment de temps pour publier un correctif avant que la vulnérabilité ne soit rendue publique. Sans cela, la sécurité des utilisateurs finaux serait compromise. Comme toujours, tout est question d’équilibre : l’objectif est de réduire à la fois la durée pendant laquelle la vulnérabilité reste confidentielle et celle pendant laquelle l’application demeure vulnérable faute de correctif.

Snyk a lancé son programme de divulgation des vulnérabilités en 2019 afin de combler cet écart et de permettre aux chercheurs de signaler des vulnérabilités facilement, tout en reconnaissant bien sûr pleinement le travail accompli pour les découvrir.

Notre équipe de sécurité examine soigneusement chaque signalement de vulnérabilité. Ce travail exige une connaissance et une compréhension approfondies du langage de programmation concerné, du package et de son contexte. Une fois les détails de la vulnérabilité vérifiés, l’équipe collabore étroitement avec les responsables du package pour qu’elle soit corrigée dans les meilleurs délais.

Enfin, en tant qu’autorité de numérotation CVE (CNA), nous aidons à attribuer un identifiant CVE au problème et à publier un avis détaillé. En 2019, nous avons contribué à divulguer plus de 130 vulnérabilités. Parmi les exemples notables : l’exécution de code à distance dans mongo-express et l’écriture de fichiers arbitraires dans yarn.

Nous collaborons avec des chercheurs indépendants, des professionnels de la sécurité et la communauté universitaire pour divulguer des vulnérabilités. Les chercheurs individuels utilisent notre programme de divulgation pour signaler une ou parfois plusieurs vulnérabilités touchant des packages. Les chercheurs universitaires, quant à eux, nous contactent pour signaler de nouveaux types de vulnérabilités et utiliser notre programme afin de divulguer à grande échelle plusieurs vulnérabilités dans l’ensemble de l’écosystème. Nous avons commencé l’année 2020 avec un partenariat majeur avec l’équipe du Security Lab de l’université Johns-Hopkins, que nous avons aidée à divulguer plus de 60 vulnérabilités (et ce n’est pas fini). Parmi les exemples notables, citons CVE-2019-10795 dans undefsafe et CVE-2019-10777 dans aws-lambda.

5. Recherche propriétaire et analyse des tendances en matière de vulnérabilités

La dernière pièce du puzzle de la sécurité est notre recherche interne et propriétaire, qui vise à découvrir et à divulguer de manière responsable de nouvelles vulnérabilités dans l’écosystème open source. Chez Snyk, nous estimons que découvrir et divulguer de manière responsable de nouvelles vulnérabilités est essentiel pour protéger l’écosystème. Pour cela, nous nous appuyons sur notre base de données de vulnérabilités existantes. En étudiant les tendances des vulnérabilités dans un langage donné ou dans plusieurs langages, nous repérons les caractéristiques clés des vulnérabilités susceptibles d’être répandues dans l’écosystème.

Autrement dit, si nous observons une vulnérabilité dans plusieurs packages de l’écosystème, tous exposés à des vecteurs d’attaque similaires, nous savons qu’il existe probablement d’autres vulnérabilités encore inconnues. Nous savons également que des acteurs malveillants pourraient en avoir connaissance et chercher à en tirer parti.

Snyk s’efforce donc d’exploiter ses capacités de recherche de manière réfléchie et efficace, soit pour découvrir de nouveaux types de vulnérabilités à grande échelle, comme zip-slip, soit pour repérer de nouveaux cas de vulnérabilités en vogue dans des packages populaires. Pour mener ces recherches, nous combinons l’analyse de données à grande échelle afin de repérer des types d’extraits vulnérables, des modèles de code ou d’autres caractéristiques similaires dans des packages potentiellement vulnérables, avec l’étude de différents vecteurs d’exploitation. Nos outils internes peuvent ensuite tester ces vecteurs sur les packages potentiellement vulnérables et déterminer s’ils le sont réellement.

Une fois les vulnérabilités découvertes, nous appliquons notre calendrier et notre méthodologie de divulgation responsable pour en informer les responsables des packages concernés et contribuer à la correction, avant de les publier dans notre base de données et de leur attribuer un CVE.

En résumé

Tous ces efforts permettent à notre produit de sécurité d’atteindre quatre objectifs essentiels :

1. Réactivité — les informations sur les vulnérabilités et les exploits parviennent à nos utilisateurs assez tôt pour qu’ils puissent agir. Ils sont souvent avertis des vulnérabilités bien avant qu’elles ne soient plus largement connues et exploitées par des acteurs malveillants.

2. Exhaustivité — les utilisateurs peuvent avoir l’esprit tranquille : ils disposent d’une vue complète des vulnérabilités et n’ont pas à craindre que d’autres vulnérabilités potentiellement exploitables se cachent dans leur base de code.

3. Précision — les données fournies sont fiables et éliminent le bruit parasite et les faux positifs redoutés lors d’une analyse de sécurité.

4. Caractère exploitable — les données permettent aux développeurs d’évaluer rapidement les vulnérabilités qui les concernent et de hiérarchiser leurs tâches en conséquence.

Grâce à ces quatre objectifs, les utilisateurs de Snyk savent que, malgré la jungle sans fin des vulnérabilités dans les écosystèmes open source, une équipe dédiée d’experts en sécurité est à leurs côtés, prête à intervenir et à leur fournir toutes les informations nécessaires pour se protéger, ainsi que le reste de l’open source.

Repérez les vulnérabilités dans votre code : créez un compte Snyk gratuit.