Améliorer l’expérience développeur grâce aux outils de sécurité chez Pinterest

Sécuriser l’utilisation des bibliothèques open source est une priorité constante dans les grandes organisations. L’un des principaux défis consiste à intégrer les outils de sécurité au workflow des développeurs et à mettre en place un système qui hiérarchise les corrections de vulnérabilités, sans pour autant les submerger. À quoi ressemble une approche efficace ?

Simon Maple (directeur technique régional chez Snyk) s’est entretenu avec Kalpesh Dharwadkar (ingénieur en sécurité des produits chez Pinterest) pour découvrir comment Pinterest s’appuie sur Snyk afin de mettre en place des pratiques de sécurité adaptées aux développeurs.

Trois grandes priorités : visibilité, analyse et triage

Pinterest utilise de nombreux logiciels open source dans sa pile de développement. Une bibliothèque open source vulnérable peut donc avoir des conséquences importantes pour l’entreprise. Avant l’arrivée de Kalpesh, l’équipe utilisait un système ponctuel reposant sur NPM audit pour créer des vues de ses bibliothèques open source. À son arrivée, Kalpesh a voulu mettre en place un système centralisé offrant une visibilité sur toutes les bibliothèques open source utilisées. Son équipe a évalué de nombreuses solutions et choisi Snyk pour deux raisons principales : ses fonctionnalités adaptées aux développeurs et la prise en charge des dépôts propres à certains langages, comme Bazel (l’outil de build retenu par l’équipe). Kalpesh a présenté ses principales priorités en matière de sécurité au début de l’échange :

Pour sécuriser l’open source chez Pinterest, nous nous concentrons sur trois éléments principaux : avoir une visibilité sur les bibliothèques vulnérables, disposer d’outils sur l’ensemble de la pile en plus de l’analyse pour trouver des correctifs, et enfin, trier les vulnérabilités.

Kalpesh a expliqué que Pinterest utilise Jenkins pour les builds. L’équipe analyse le système de build avec la Snyk CLI, puis importe les résultats dans l’interface web de Snyk. Son premier objectif est d’avoir une visibilité sur toutes les dépendances présentes dans ses dépôts de code et de prioriser la correction des vulnérabilités. Elle s’est donc intéressée au Common Vulnerability Scoring System (CVSS), qui offre une visibilité sur les vulnérabilités. Lorsqu’un exploit existe, elle s’appuie sur les informations de Snyk pour déterminer si la correction est hautement prioritaire.

Intégrer des tests de sécurité tout au long du pipeline

Simon a ensuite posé des questions sur les tests tout au long du pipeline de développement et sur les difficultés rencontrées pour apprendre aux développeurs à utiliser Snyk. Kalpesh a une solution simple. Lorsqu’il a commencé à intégrer Snyk au pipeline des développeurs, au lieu de leur donner accès à la console Snyk, il a ajouté l’analyse comme étape du build Jenkins. Il s’est ensuite chargé de quelques « corrections faciles », puis a demandé à des responsables techniques ou aux propriétaires de projets de vérifier son travail. Cela les a incités à appliquer eux-mêmes des correctifs avec les outils Snyk et a favorisé une adoption plus large.

Trier efficacement, prioriser les corrections et gérer Log4Shell

La discussion s’est tournée vers le triage des vulnérabilités. Simon a demandé : « Quels signaux ou signes d’alerte recherchez-vous dans votre backlog pour pouvoir dire aux développeurs : “voici les cinq vulnérabilités à traiter en priorité” ? » Kalpesh évalue la gravité de la vulnérabilité, l’existence d’un exploit actif et la présence de la vulnérabilité dans un service exposé à Internet. Il s’appuie sur ces critères pour définir la priorité des corrections. Un ticket est ensuite créé et attribué à un développeur ou au responsable du service pour corriger la vulnérabilité. Le suivi dans le ticket aide son équipe à vérifier si son évaluation de la vulnérabilité correspond aux priorités des développeurs.

Le ticket est attribué à un développeur. Il peut nous répondre : « Hé, nous n’utilisons pas cette fonctionnalité particulière qui est vulnérable dans cette dépendance. » Dans ce cas, nous essayons de revoir la priorité de cette fonctionnalité à la baisse.

Alors que la conversation s’orientait vers Log4Shell, Simon a demandé à Kalpesh comment Pinterest avait géré une vulnérabilité zero-day majeure. Kalpesh se souvient que, le lendemain matin de l’annonce de Log4Shell, son équipe a déclaré un incident afin de déterminer combien de services étaient touchés. Un indicateur JVM (ou une solution de contournement) était disponible. L’équipe l’a appliqué à ses services Java, mais a dû compter sur les responsables des services pour déployer les changements, ce qui prend du temps. Le déploiement de la solution de contournement a occupé l’équipe jusqu’au week-end, car elle voulait s’assurer que tous les services utilisaient l’indicateur JVM. Deux axes de travail ont été définis : repérer tous les services Java de Pinterest et détecter les services que la solution de contournement par indicateur JVM ne couvrirait pas. Pour les services où cet indicateur ne suffisait pas, seule une mise à jour pouvait atténuer la menace. Kalpesh a ajouté que Log4Shell leur avait notamment appris l’importance de disposer d’un tableau de bord unique présentant tout ce qui tourne en production.

Automatiser les analyses pour permettre au développement d’avancer

Pour revenir à l’utilisation de Snyk chez Pinterest, Simon a demandé dans quelle mesure Snyk avait réduit les tâches manuelles de Pinterest grâce à l’autonomie des développeurs, et quel niveau de visibilité l’équipe avait sur leurs pipelines.

Chez Pinterest, nous utilisons des mono-dépôts propres à chaque langage. Une fois un mono-dépôt ajouté à Snyk, tout nouveau projet créé dans ce dépôt est automatiquement ajouté. Il n’y a donc aucune tâche supplémentaire à effectuer à la création d’un projet. Une fois le code fusionné dans le dépôt et l’analyse Snyk exécutée, nous savons quelles dépendances ont été ajoutées. [Lorsqu’un développeur crée un projet dans son mono-dépôt, l’analyse est] transparente pour lui. Il n’a même pas besoin de savoir que Snyk s’exécute.

Avec cette configuration, chaque nouveau projet créé par un développeur est automatiquement analysé et envoyé dans l’interface Snyk, ce qui permet à l’équipe de Kalpesh d’avoir une vue d’ensemble.

Simon remarque que les développeurs préfèrent généralement rester dans leur workflow plutôt que de passer à d’autres outils. Il a demandé à Kalpesh : « Comment avez-vous organisé les choses pour que les développeurs puissent rester dans leurs pipelines ? »

Kalpesh confirme que les développeurs aiment « rester dans leurs tickets » tout en ayant accès à toutes les informations nécessaires. Il mentionne le centre de formation de Snyk, qui propose des ressources pédagogiques aux développeurs. Il explique que l’accès à ce programme l’amène à envisager de donner aux développeurs davantage accès à la console web de Snyk, ou d’ajouter dans les tickets JIRA un lien vers les informations pertinentes de Snyk Learn, afin de leur donner plus de contexte sur des vulnérabilités comme les attaques XSS ou les injections SQL. C’est un moyen efficace d’encourager les développeurs à approfondir leurs connaissances en sécurité.

Laisser les développeurs travailler là où ils le souhaitent

Dans l’ensemble, Kalpesh et son équipe chez Pinterest privilégient un workflow adapté aux développeurs, en mettant l’accent sur le triage pour éviter de les submerger. Il indique qu’au début de l’intégration de Snyk, ils ont découvert un grand nombre de vulnérabilités dans leurs dépendances. Il était donc essentiel de ne faire remonter que celles qui étaient prioritaires pour l’entreprise. L’automatisation des analyses et la consultation des résultats avec Snyk, tout en laissant les développeurs utiliser leurs outils préférés, permettent à Pinterest de poursuivre ses développements sans heurts.

Les développeurs veulent savoir : quel est le problème, comment le corriger et quelle est sa priorité. Si vous pouvez indiquer ces éléments dans un ticket destiné à un développeur, vous avez tout bon.