Skip to main content

Même les non-développeurs peuvent corriger des vulnérabilités dans le code avec The Big Fix

Écrit par
Headshot of Gerald Crescione

Gerald Crescione

blog hero the big fix

23 février 2022

0 minutes de lecture

Voici comment une tâche courante de gestion de projet m’a amené à ouvrir une pull request dans un dépôt open source sur GitHub.

En tant que nouvelle recrue dans l’équipe marketing de Snyk, j’ai récemment participé à la préparation de The Big Fix, un événement qui réunit des développeurs, des spécialistes DevOps et des professionnels de la sécurité de tous niveaux pour contribuer à rendre Internet plus sûr en corrigeant des vulnérabilités, tout en s’amusant et en remportant des cadeaux.

Tout le monde est invité à participer. Pourquoi ne corrigerais-je pas moi-même une vulnérabilité ?

En discutant avec l’équipe, j’ai compris que le processus était si simple qu’une personne sans compétences techniques comme moi pouvait participer à l’initiative et contribuer activement à cet effort mondial pour rendre Internet plus sûr. J’ai donc décidé de tenter ma chance.

Étape 1 : Premiers pas avec Snyk

L’inscription à The Big Fix était simple. Il me suffisait d’utiliser mon compte Snyk, entièrement gratuit et activable en quelques minutes. En tant que spécialiste du marketing, je ne peux pas dire que j’utilisais beaucoup la plateforme. J’avais simplement créé mon compte pour découvrir le produit et comprendre globalement son fonctionnement.

L’étape suivante consistait à connecter Snyk à mon compte GitHub et à accorder à la plateforme les autorisations par défaut pour analyser mes projets et proposer des correctifs aux vulnérabilités, dans la mesure du possible.

Paramètres de l’intégration GitHub de Snyk affichant la configuration du compte pour ouvrir des pull requests Snyk à l’aide d’un jeton d’accès personnel

Étape 2 : Choisir le bon projet

Une fois mon compte configuré et connecté à GitHub, je pouvais importer un projet et l’analyser à la recherche de vulnérabilités. Je devais maintenant choisir le bon projet auquel contribuer. Je n’ai pas de projets personnels, seulement quelques petits bouts de code sans grande importance. Je devais donc contribuer à un autre projet. Dans l’idéal, il serait open source et lié à l’écosystème cloud-native, mon domaine d’origine.

En effet, au cours de mes expériences précédentes, j’ai travaillé dans des start-up et sur des projets axés sur l’Infrastructure as Code (IaC). J’ai eu l’occasion de rédiger quelques articles de blog présentant tous les outils open source intéressants gravitant autour de Hashicorp Terraform, qui facilitent encore davantage la gestion des ressources cloud. Voici la courte liste d’outils que j’avais en tête :

  • Terraformer (aussi appelé « reverse Terraform ») : un outil open source très pratique, créé par l’équipe SRE de Waze, qui analyse les infrastructures cloud existantes créées manuellement et les convertit en code Terraform, ce qui permet de les réimporter dans votre base de code IaC.

  • TFlint : un linter qui analyse statiquement votre code Terraform, repère les types d’instances non valides et détecte instantanément les fautes de frappe et les incohérences.

  • Terratest : une bibliothèque Go qui exécute des tests d’intégration sur vos fichiers Terraform.

J’ai choisi Terratest, car j’apprécie que l’équipe derrière cet outil se soucie de tester nos infrastructures, une bonne pratique qui, soyons honnêtes, n’est probablement pas encore très répandue.

Si vous ne connaissez pas cet outil, voici une brève présentation : Terratest a été créé par nos amis de Gruntwork. Cette puissante bibliothèque Go vous permet d’intégrer votre code Terraform et de le manipuler par programmation pour faire absolument tout ce que vous voulez, et ainsi réaliser tous les tests d’intégration dont vous avez besoin.

Étape 3 : Choisir le bon correctif

Pour commencer, je devais analyser Terratest afin de vérifier si le dépôt contenait des vulnérabilités. J’ai simplement créé une fork de leur dépôt public, puis importé cette fork dans Snyk pour l’analyser.

Tableau de bord Snyk Projects affichant les dépôts GitHub importés, le nombre de problèmes par niveau de gravité et des filtres par statut de projet et intégration.

Soyons honnêtes : je ne suis pas développeur. Mes compétences sont très limitées et, lorsque je touche au code, je ne suis généralement pas en mesure d’apporter grand-chose. Pourtant, je tenais vraiment à participer à The Big Fix et à contribuer, même modestement, à ce formidable projet Terratest.

En analysant le projet, j’ai eu la chance de trouver un correctif très simple (mettre à niveau une image Docker) que je pouvais appliquer.

Tableau de bord Snyk Projects affichant une liste de projets consultable, le nombre de problèmes par niveau de gravité, des filtres et des catégories d’intégration.

Avec Snyk, tout le monde peut facilement détecter et corriger un problème, quel que soit son niveau de compétence. Il suffit de cliquer sur le bouton Ouvrir une PR de correction pour accéder à votre dépôt et obtenir une proposition de correctif adaptée à la vulnérabilité.

Vue d’ensemble d’un Dockerfile dans Snyk présentant des recommandations de mise à niveau de l’image de base, le nombre de vulnérabilités, leur niveau de gravité et un bouton « Ouvrir une PR de correction ».

J’ai particulièrement apprécié de pouvoir explorer la plateforme plus en détail et consulter la documentation pour mieux comprendre cette vulnérabilité et les risques qu’elle présentait. En l’occurrence, il s’agissait de mettre à jour une ancienne version d’une image.

Page Snyk User Docs expliquant la détection des images de base et les méthodes d’identification des images de conteneur vulnérables.

À vos marques, prêts, corrigez !

Tout était prêt : la vulnérabilité était détectée, le correctif préparé. Il ne me restait plus qu’à cliquer sur le bouton Ouvrir une PR de correction pour accéder à GitHub.

Page d’ouverture d’une pull request de correction pour mettre à niveau l’image de base d’un Dockerfile, de ruby:2.6.2-stretch à ruby:2.6.8-stretch

Dans mon dépôt, il m’a été très facile d’examiner le correctif et de décider si je voulais le fusionner. Évidemment, je l’ai fait. (N’oubliez pas qu’il y a des cadeaux à gagner.)

Pull request GitHub de Snyk proposant une mise à niveau de sécurité de l’image de base Ruby Docker, avec un tableau répertoriant les vulnérabilités.

La fusion de la PR était un jeu d’enfant et m’a laissé un sentiment exaltant d’utilité et de satisfaction.

Interface de pull request GitHub indiquant que toutes les vérifications ont réussi, qu’il n’y a aucun conflit de fusion et affichant le bouton vert « Merge pull request ».

Attendez ! Je viens de corriger une vulnérabilité dans un dépôt privé que je n’utilise même pas vraiment.

Créer une fork d’un dépôt public uniquement pour l’analyser et y corriger une vulnérabilité ne sert à rien. Et même si la perspective de gagner un t-shirt en édition limitée est séduisante, je voulais vraiment apporter une contribution concrète, aussi modeste soit-elle.

Pas de problème ! Il me suffisait de copier le correctif et d’envoyer une PR au dépôt Terratest d’origine sur GitHub.

Page de comparaison des modifications sur GitHub montrant la mise à jour d’un Dockerfile, de ruby:2.6.2-stretch à ruby:2.6.8-stretch, avec une option pour créer une pull request

Et voilà ! Corriger une vulnérabilité, c’est amusant. Contribuer à l’open source, c’est encore mieux.

Corriger une vulnérabilité mérite toujours de s’en vanter et de faire la fête.

Ai-je mentionné la communauté autour de The Big Fix ?

L’un des aspects intéressants de ce projet, c’est qu’il s’inscrit dans une communauté. C’est sur le serveur Discord de la communauté DevSecCon que tout se passe. Une fois sur le serveur, vous pouvez rejoindre le canal the-big-fix, discuter avec d’autres développeurs des correctifs que vous avez apportés et échanger sur la sécurité de l’information et le DevSecOps.

Message de la communauté remerciant Hacker Kyle pour ses conseils, accompagné d’une capture d’écran d’une pull request GitHub visant à mettre à jour l’image Docker de Terratest.

Comment corriger des vulnérabilités dans la sécurité des applications tout en s’amusant ?

The Big Fix vise à aider à détecter et corriger des vulnérabilités de manière ludique, en récompensant les participants avec des cadeaux. Le principe est très simple. Il suffit de :

  1. Vous inscrire à The Big Fix.

  2. Vous connecter à votre compte Snyk (ou en créer un gratuitement si vous n’en avez pas).

  3. Importer un projet et l’analyser.

  4. Trouver une vulnérabilité (oui, vos projets en contiendront probablement, même si vous faites très attention).

  5. La corriger en créant une PR depuis la plateforme Snyk.

  6. (Étape facultative) Installez-vous confortablement et imaginez à quel point vous aurez fière allure avec votre t-shirt The Big Fix en édition limitée.

  7. Importer et analyser d’autres projets pour corriger encore plus de vulnérabilités.

Si vous souhaitez participer à cette initiative, plusieurs ressources peuvent vous aider à vous lancer. Une recherche rapide de #TheBigFix sur Twitter est sans doute le meilleur point de départ. Vous pouvez aussi regarder la vidéo ci-dessous, qui explique comment commencer à corriger des vulnérabilités avec l’IDE VS Code.

The Big Fix 2022 - Getting started with VS Code IDE security fixes

Et maintenant ?

N’oubliez pas que The Big Fix est un événement qui dure un mois. Il a commencé le 18 janvier et se terminera le 25 février par un « Big Fix-a-Thon », un événement diffusé en direct pendant 24 heures, consacré au DevSecOps et à la sécurité des développeurs. Bonne nouvelle : inutile d’attendre le 25 février pour trouver une vulnérabilité à corriger. Au moment où j’écris cet article, 35 302 projets ont déjà été analysés, 454 116 vulnérabilités détectées et 82 109 corrigées. C’est incroyablement enthousiasmant !

Participez au Big Fix-a-Thon interactif du 25 février, un événement diffusé en direct pendant 24 heures sur le DevSecOps et la sécurité des développeurs, avec des séquences divertissantes et des intervenants exceptionnels qui vous accompagneront dans votre parcours de correction.

Participez à The Big Fix

Rejoignez les milliers de développeurs qui sécurisent actuellement leurs applications avec Snyk.

Lire la suite

blog feature snyk container custom base recommendations
Blog

Découvrez Evo Agentic AppSec : une sécurité au rythme du développement de l’IA

Le développement piloté par l’IA dépasse les workflows de sécurité traditionnels. L’AppSec agentique de Snyk s’appuie sur des agents de sécurité pour détecter, corriger et vérifier les vulnérabilités en continu, tandis que les équipes définissent les exigences.

blog feature ai violet
Blog

VulnBump : les agents IA peuvent-ils corriger les dépendances vulnérables sans casser le build ?

VulnBump évalue des agents IA sur 307 mises à niveau de dépendances réelles. Une correction n’est comptabilisée que si la vulnérabilité disparaît et que la compilation et les tests restent au vert.

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.