SurveyMonkey échange avec Snyk sur la sécurité des développeurs en période d’hypercroissance

De nombreuses entreprises confient aux RSSI ou aux équipes de conformité la gestion de la sécurité tout au long du développement logiciel. Mais cette pratique tend à dissocier les considérations de sécurité du travail des développeurs. Les RSSI peuvent leur attribuer des tâches de sécurité, mais si les développeurs ne pensent pas régulièrement à la sécurité, ces tâches risquent d’être négligées. Pour combler cet écart, une solution consiste à faire appel à un responsable de l’ingénierie de la sécurité (similaire à un référent sécurité) — une personne qui défend la sécurité comme partie intégrante du processus d’ingénierie.

Lors d’une récente table ronde, Simon Maple, Field CTO chez Snyk, a échangé avec Craik Pyke, directeur principal de l’ingénierie de la sécurité, du cloud et des magasins de données chez SurveyMonkey (qui fait désormais partie de Momentive). Ils ont discuté de l’utilisation d’outils offrant une meilleure visibilité et de la mise en place d’un parcours balisé pour inciter les développeurs à se concentrer sur la sécurité dans les organisations en hypercroissance. SurveyMonkey utilise Snyk Open Source, Snyk Container et Snyk Code pour intégrer la sécurité tout au long du processus de développement. Voici le résumé de leur échange.

Assurer cohérence et visibilité

Lorsque Craik a rejoint SurveyMonkey, l’entreprise utilisait une architecture de microservices. Chaque équipe était responsable de ses propres services, de la conception au déploiement et à l’assistance, en passant par la création. Les équipes faisaient donc comme bon leur semblait : chacune ajoutait des plug-ins à ses propres pipelines et utilisait les outils de son choix. Il devenait alors difficile d’assurer la traçabilité. Il n’existait aucun suivi clair de la provenance des conteneurs utilisés par les développeurs ni du nombre de dépendances qu’ils avaient. Dans ce contexte, la principale préoccupation de Craik concernait la gestion de l’open source. Il s’est demandé s’il était possible de suivre l’utilisation des licences ou de produire une déclaration d’attribution fiable. Mais comme tout était géré manuellement, la réponse était généralement non.

[Les développeurs disaient] : « Mes projets comptent 80 000 dépendances. Comment savoir ce que j’intègre ? Et dois-je rechercher toutes ces licences ? » C’est là que nous avons commencé : nous devions aider les développeurs à répondre à ces questions, sans leur imposer des contraintes au seul motif qu’il s’agissait de sécurité.

Fort de son expérience, Craik savait que c’était le premier défi à relever : instaurer la visibilité et mettre en place une gouvernance. Il avait auparavant travaillé dans une entreprise qui lançait rapidement ses produits, mais la possibilité de comprendre les versions des packages et les risques liés à l’open source n’avait été prise en compte qu’après la demande d’un client. Chez SurveyMonkey, il a donc commencé par réfléchir à la cohérence avant de penser à la visibilité. Il voulait instaurer une culture DevOps, dans laquelle les développeurs pourraient confier la création d’un pipeline à un groupe désigné, chargé de le gérer. Une fois les équipes convaincues par cette idée, il a été facile de créer un pipeline unique pour les builds. L’obtention de cet artefact de build constituait la première étape. Il s’est ensuite rapidement intéressé aux outils permettant d’améliorer la visibilité au-delà du pipeline, jusque dans les activités des développeurs sur leurs machines.

Fournir de meilleurs outils et de meilleures données

Les développeurs aiment trouver eux-mêmes des solutions : ils intègrent tout ce dont ils ont besoin pour résoudre un problème sur leur machine ou dans leur IDE. Craik voulait décrire et définir ce qu’ils intégraient pendant la phase de prototypage. Il souhaitait leur fournir des outils qui reproduiraient le fonctionnement du pipeline de build, dans leur IDE ou leur ligne de commande.

Comment fournir aux [développeurs] des outils aussi performants sur leur machine que dans le pipeline de build ? Repérer les outils adaptés et les déployer… Les développeurs les ont adoptés facilement dès qu’ils ont compris qu’ils reproduisaient le pipeline. La cohérence est essentielle.

Il voulait également fournir de bonnes données aux développeurs. Par exemple, leur permettre de déterminer facilement si un package convient à un projet ou s’il vaut mieux en choisir un autre. Pour cela, rien de mieux que les données. Lorsqu’ils savent qu’ils peuvent utiliser Snyk Advisor et trouver rapidement des indicateurs — la popularité d’un package ou la date de son problème le plus récent, par exemple — ils comprennent la complexité de la situation. Selon Craik, c’est l’un des facteurs qui l’ont décidé à accepter son poste actuel : fournir des données fiables aux développeurs, puis leur faire confiance pour prendre les bonnes décisions.

Mettre en place un parcours balisé

Craik s’est ensuite attelé à la mise en place d’une infrastructure de build commune. Il a utilisé un dépôt d’artefacts partagé (dans son cas, Artifactory, mais il existe de nombreuses solutions). L’objectif principal était que les développeurs récupèrent toujours les artefacts depuis le registre. C’est une étape essentielle dans une organisation en hypercroissance, où l’augmentation du nombre de développeurs peut entraîner celle d’une infrastructure qui échappe à tout contrôle. Mais Craik ne voulait pas que l’équipe de sécurité joue les bloqueurs. Elle disait aux développeurs : « Configurez votre fichier de configuration préféré pour qu’il pointe vers ce système d’artefacts. Si l’élément recherché ne s’y trouve pas, le système le récupérera pour vous. Il vous aidera. » Il a d’abord fallu convaincre les développeurs de changer leurs habitudes. Mais dès que tout le monde a commencé à récupérer ses artefacts depuis ce cluster unique, l’équipe a pu savoir ce qui était utilisé, où et quand, ainsi que les versions en cours.

L’équipe de Craik autorisait les développeurs à travailler en dehors de leur pipeline, mais dès qu’ils tentaient de soumettre une PR, celle-ci échouait. Le pipeline de build qui exécute leurs tests depuis GitHub n’était pas autorisé à accéder directement à Internet : il récupérait uniquement les éléments depuis leur dépôt d’artefacts. Ainsi, si les développeurs avaient pris d’emblée l’habitude attendue et utilisaient le dépôt d’artefacts, aucun problème ne se posait.

Comment éviter que les développeurs perçoivent la sécurité comme un obstacle ? Nous avons adopté une approche bienveillante. Nous avons toujours privilégié les encouragements. Nous leur disions : « Si vous passez par le dépôt d’artefacts unique, vous n’avez pas à vous inquiéter des packages malveillants ou des licences non conformes, car nous pouvons analyser les éléments dès leur arrivée. Nous pouvons veiller à ce que vous ne fassiez pas de mauvais choix. » Les développeurs ont ainsi cessé de voir la sécurité comme un adversaire et l’ont considérée comme une équipe à qui poser des questions et qui y répond. Nous sommes là pour aider, pas pour freiner.

Les référents sécurité : une initiative de terrain

Pendant que l’équipe de Craik entretenait le parcours balisé, certains développeurs de SurveyMonkey sont progressivement devenus des référents sécurité. Les plus expérimentés ont appris aux nouveaux membres de l’équipe à utiliser le dépôt d’artefacts, à repérer les signaux dans les PR et à savoir à qui poser leurs questions. Craik décrit cette approche comme « une idée assez informelle consistant à intégrer le support de premier niveau aux équipes de développement ». Il n’a pas formalisé de programme de référents sécurité, car au fil des arrivées dans l’équipe, l’attention portée à la sécurité est simplement devenue une habitude acquise.

Lorsque les développeurs contrôlent eux-mêmes la sécurité de leur code, l’équipe de sécurité peut jouer un rôle de facilitateur et les aider en cas de besoin. Craik souligne qu’avec un parcours balisé et un ensemble d’outils adaptés — notamment les outils Snyk, qui facilitent la détection et la correction des vulnérabilités — l’équipe de sécurité peut relancer les builds des artefacts si nécessaire, sans avoir à solliciter les développeurs.

Les données fournies par nos outils et notre pipeline permettent vraiment aux développeurs de faire des choix éclairés.

Partager responsabilités et objectifs

Dans une culture de shift left réussie, les développeurs veulent prendre en charge les exigences de sécurité dès le départ. La validation leur permet d’avancer plus rapidement dans leur travail générateur de revenus. L’équipe de sécurité ne dit pas aux développeurs : « Vous devez suivre ces étapes pour des raisons de sécurité. » Au contraire, les développeurs viennent la voir et lui demandent : « J’ai repéré un problème dans ce package. Puis-je continuer ? » L’équipe s’efforce également de partager la responsabilité : au lieu de chercher un responsable lorsqu’une vulnérabilité a pu passer inaperçue, elle corrige le problème aussi rapidement que possible, puis discute des leçons à en tirer.

Soutenir les développeurs, c’est aussi leur permettre de s’entraider. Lorsque l’équipe de Craik a déployé Snyk pour détecter les vulnérabilités, elle n’a pas bloqué les PR dans GitHub. Elle a plutôt laissé les développeurs les plus expérimentés accompagner les plus juniors lors des revues de code et de PR. Un développeur senior pouvait leur dire : « Cette croix rouge indique un problème. Oui, techniquement, vous pouvez quand même fusionner le code, mais voici ce qui se passe actuellement. » Aucune mesure coercitive n’a été imposée dès le premier jour ; l’équipe a plutôt bâti une culture collaborative. Pour les équipes de SurveyMonkey, la meilleure approche consistait à déployer les outils Snyk au niveau qui leur convenait.

Regardez l’intégralité de l’échange pour découvrir d’autres éclairages précieux sur la sécurité destinés aux développeurs.