Améliorer l’expérience des développeurs avec des outils de sécurité chez Pinterest

L’utilisation sécurisée des bibliothèques open source est une priorité constante dans les grandes organisations. L’un des grands défis consiste à intégrer les outils de sécurité dans le workflow des développeurs, et à mettre en place un système qui priorise les solutions apportées aux vulnérabilités, sans submerger les développeurs. Mais à quoi ressemble une approche réussie ?

Notre Simon Maple (Field CTO, Snyk) s’est entretenu avec Kalpesh Dharwadkar (Product Security Engineer, Pinterest) pour savoir comment Pinterest utilise Snyk pour mettre en place des pratiques de sécurité conviviales pour les développeurs.

Trois grandes axes prioritaires : visibilité, analyse et tri

Pinterest utilise de nombreux logiciels open source dans sa pile de développement, de sorte qu’une bibliothèque open source vulnérable peut indéniablement affecter son profil exécutif. Avant l’arrivée de Kalpesh, l’entreprise utilisait un système ad hoc pour créer des vues de ses bibliothèques open source au moyen de l’audit NPM. Kalpesh, lui, a souhaité mettre en place un système centralisé pour obtenir une visibilité sur toutes les bibliothèques open source utilisées. Son équipe a évalué de nombreuses solutions et a choisi Snyk pour deux raisons principales : ses fonctionnalités conçues pour les développeurs et la prise en charge de référentiels spécifiques à certains langages comme Bazel (leur outil de développement). Kalpesh décrit ses principales priorités en matière de sécurité dès le début de la conversation :

Pour la sécurité de l’open source chez Pinterest, nous nous concentrons sur trois axes principaux : obtenir une visibilité sur les bibliothèques vulnérables, outiller l’ensemble de la pile en plus de l’analyse pour les correctifs, et enfin, trier les vulnérabilités.

Kalpesh explique qu’ils utilisent Jenkins pour les builds. Ils analysent le système de build à l’aide de la CLI de Snyk, puis téléchargent les résultats dans l’interface Web de Snyk. L’objectif premier est d’obtenir une visibilité sur l’ensemble des dépendances de leurs référentiels de code, et de prioriser la correction des vulnérabilités. L’équipe s’est donc intéressée au système standardisé de notation des vulnérabilités (CVSS), qui offre une visibilité sur les vulnérabilités. Si un exploit existe, ils utilisent les informations de Snyk pour déterminer s’il s’agit d’une correction prioritaire.

Ajouter des tests de sécurité tout au long du pipeline

Simon a ensuite posé des questions sur les tests effectués tout au long du pipeline de développement et sur les défis rencontrés en matière de formation des développeurs à l’utilisation de Snyk. Kalpesh propose une solution simple pour cette étape. Lorsqu’il a commencé à introduire Snyk dans le pipeline des développeurs, au lieu d’exposer la console Snyk à ses développeurs, il a fait exécuter l’analyse comme une étape du build Jenkins. Il a ensuite commencé à s’occuper lui-même de certaines solutions qui étaient à portée de main (les corrections simples), puis a fait réviser son travail par des responsables techniques ou des chefs de projet. Cela les a incités à appliquer les corrections au moyen des outils Snyk et a permis d’obtenir une adhésion plus large.

Tri efficace, priorisation des corrections et gestion de Log4Shell

La discussion a porté sur le tri des vulnérabilités. Simon a posé la question suivante : « Quel type de signaux ou de drapeaux rouges recherchez-vous pour pouvoir présenter aux développeurs les cinq principales vulnérabilités qu’ils devraient examiner ? » La solution de Kalpesh consiste à prendre en compte la gravité de la vulnérabilité, l’existence d’un exploit actif et le fait que la vulnérabilité se trouve ou non dans un service exposé à l’Internet. Ce sont les paramètres qu’il utilise pour définir la priorité des corrections. Un ticket est ensuite créé afin qu’un développeur ou un propriétaire de service corrige la vulnérabilité. Le suivi des informations contenues dans le ticket permet à son équipe de comprendre si son évaluation de la vulnérabilité est conforme à ce que les développeurs jugent important.

Le ticket est affecté au développeur. Il peut revenir vers nous en disant : « Nous n’utilisons pas cette fonctionnalité spécifique qui est vulnérable à la dépendance ». Dans ce cas, nous essayons de réduire la priorité de la fonctionnalité.

Alors que la conversation s’orientait vers Log4Shell, Simon a demandé à Kalpesh comment Pinterest gère une importante vulnérabilité de type « zero-day ». Kalpesh a rappelé que le matin suivant l’annonce de Log4Shell, son équipe a déclaré un incident visant à explorer le nombre de services affectés. L’équipe a appliqué aux services Java un indicateur JVM (ou solution de contournement) disponible. Toutefois, le déploiement de tous les services relevant des propriétaires des services, cela a pris du temps. Le déploiement de la solution de contournement a duré pendant le week-end, car l’équipe voulait s’assurer que tous les services avaient été déployés avec l’indicateur JVM. Deux flux de travail ont été établis : l’un pour détecter tous les services Java dans Pinterest, l’autre pour détecter d’éventuels services non couverts par la solution de contournement de l’indicateur JVM. Les services pour lesquels l’indicateur JVM n’était pas suffisant nécessitaient une mise à jour (seul moyen d’atténuer la menace). Selon Kalpesh, une leçon importante retirée de l’incident Log4Shell est la nécessité de disposer d’un tableau de bord unique regroupant tous les éléments en production.

Automatiser les analyses pour soutenir la progression du développement

Concernant l’utilisation de Snyk par Pinterest, Simon cherchait à quantifier dans quelle mesure Snyk a permis de réduire l’effort manuel de Pinterest en termes de libre-service pour les développeurs, et de quelle visibilité ils disposaient sur les pipelines des développeurs.

Chez Pinterest, nous utilisons des référentiels mono spécifiques à chaque langage. Une fois que vous ajoutez un référentiel mono à Snyk, tout nouveau projet créé dans ce référentiel est automatiquement ajouté. Ainsi, aucun travail supplémentaire n’est requis lors de la création d’un nouveau projet dans ce référentiel. Une fois le code fusionné dans le référentiel et l’analyse Snyk effectuée, nous avons une visibilité sur les dépendances qui ont été introduites. \[Lorsqu’un développeur crée un projet dans son référentiel mono, l’analyse est] transparente pour lui. Il n’a même pas besoin de savoir que Snyk est en cours d’exécution.

Avec cette configuration, chaque fois qu’un développeur crée un projet, celui-ci est automatiquement analysé et poussé vers l’interface utilisateur de Snyk, ce qui permet à l’équipe de Kalpesh de tout voir de haut en bas.

Simon fait remarquer que les développeurs préfèrent généralement rester dans leur propre workflow que d’aller vers d’autres outils. Il demande à Kalpesh comment il s’organise pour que les développeurs puissent rester dans leurs pipelines.

Kalpesh admet cela, tout en gardant à l’esprit tout ce que les développeurs ont besoin de savoir. Il mentionne le hub d’apprentissage de Snyk, qui contient des ressources éducatives pour les développeurs. Kalpesh dit qu’accéder à ce programme l’amène à envisager d’exposer les développeurs à une plus grande partie de la console web Snyk, ou éventuellement d’ajouter un lien vers les informations pertinentes de Snyk Learn dans le ticket sur JIRA, afin de fournir aux développeurs plus de contexte autour des vulnérabilités de type XSS ou injection SQL. C’est là un moyen utile d’encourager les développeurs à développer leurs connaissances en matière de sécurité.

Garder les développeurs là où ils veulent être

Dans l’ensemble, Kalpesh et son équipe chez Pinterest valorisent un workflow conçu pour les développeurs et mettant l’accent sur le tri afin de leur éviter d’être submergés. Il note que lors de la première intégration avec Snyk, ils ont constaté un grand nombre de vulnérabilités provenant de leurs dépendances, d’où l’importance de ne faire apparaître que celles qui étaient hautement prioritaires pour l’entreprise. La possibilité d’automatiser les analyses et de visualiser les résultats avec Snyk, tout en permettant aux développeurs d’évoluer avec les outils de leur choix, aide Pinterest à assurer le bon déroulement du développement.

Les développeurs veulent savoir quel est le problème, comment le solutionner et quelle est la priorité. Si vous pouvez spécifier ces éléments dans le ticket d’un développeur, vous êtes prêt.