SurveyMonkey échange avec Snyk autour de la sécurité des développeurs chez les entreprises en hypercroissance

De nombreuses entreprises se tournent vers leur CISO ou leurs équipes de conformité pour gérer la sécurité tout au long du développement logiciel. Le problème, c’est que cette approche tient les développeurs à l’écart de cette problématique. Certes, les CISO peuvent attribuer des tâches relevant de la sécurité aux développeurs, mais si ces derniers ne s’en préoccupent pas régulièrement, ils risquent de les négliger. Une solution à ce problème consiste à nommer un responsable de l’ingénierie de sécurité (à la manière d’un ambassadeur de la sécurité), qui replace la sécurité au cœur du processus global d’ingénierie.

Lors d’une récente table ronde, Simon Maple, Field CTO de Snyk, a échangé avec Craik Pyke, directeur de la sécurité, du cloud et de l’ingénierie des dépôts de données chez SurveyMonkey (qui fait désormais partie de Momentive). Les deux hommes ont discuté des outils qui offrent de la visibilité et ouvrent la voie à une approche encourageant les développeurs à se concentrer de la sécurité au sein des entreprises en hypercroissance. SurveyMonkey a opté pour Snyk Open Source, Snyk Container et Snyk Code afin d’intégrer la sécurité à l’ensemble de son processus de développement. Voici un résumé de leurs échanges.

Assurer visibilité et cohérence

Quand Craik Pyke a rejoint SurveyMonkey, l’entreprise s’appuyait sur une architecture de microservices. Chaque équipe était responsable de ses propres services, notamment de la conception, de la construction, du déploiement et du support. Naturellement, chaque équipe menait sa barque à sa manière, en ajoutant des plugins à ses pipelines et en utilisant ses outils préférés. Autant dire que la traçabilité était particulièrement complexe. Personne ne suivait exactement où les développeurs se procuraient leurs conteneurs ni leur nombre de dépendances. Dans un tel contexte, la plus grande préoccupation de Craik Pyke était la gestion de l’open source. Il a demandé s’il était possible de suivre l’utilisation des licences ou de créditer de manière fiable les auteurs des différents composants. Tout étant géré manuellement, la réponse à ses questions était généralement négative.

\[Les développeurs lui expliquaient] : « J’ai 80 000 dépendances dans mes projets. Comment pourrais-je savoir ce que j’intègre ? Et je dois vraiment aller vérifier toutes les licences ? » C’est par là que nous avons commencé : nous devions aider les développeurs à répondre à nos questions, et non les forcer à suivre des procédures au simple prétexte que la sécurité était en jeu.

D’expérience, Craik Pyke savait qu’il s’agissait là du premier défi à relever : donner de la visibilité et mettre en place un système de gouvernance. Il avait précédemment travaillé au sein d’une entreprise qui livrait ses produits rapidement, mais qui ne se préoccupait pas des versions des paquets ou des risques liés à l’open source jusqu’à ce qu’un client ne l’interroge sur le sujet. Chez SurveyMonkey, avant même de penser à la visibilité, il s’est donc penché sur la question de la cohérence. Il lui fallait établir une culture DevOps dans laquelle les développeurs pourraient confier la création et la gestion d’un pipeline à un groupe dédié. Une fois cette idée vendue aux intéressés, la création d’une pipeline de développement unique n’a posé aucune difficulté. La mise en place de cet artefact de développement constituait la première étape. Il s’est ensuite rapidement intéressé aux outils nécessaires pour bénéficier d’une visibilité allant au-delà du pipeline, sur l’activité des développeurs sur leurs machines.

Fournir de meilleurs outils et de meilleures données

Les développeurs aiment résoudre les puzzles : ils intègrent sur leur propre machine ou leur IDE toutes les ressources dont ils ont besoin pour résoudre un problème. Craik Pyke voulait que ces ressources intégrées pendant la phase de prototype soient répertoriées et définies. Le but était que les développeurs disposent d’outils identiques dans le pipeline de développement et leur IDE ou de la commande line.

Comment pouvons-nous fournir \[aux développeurs] des outils efficaces, et qui sont identiques sur leur machine et dans la pipeline de développement ? Trouver ces outils et les déployer n’a finalement pas posé de difficulté aux développeurs une fois qu’ils ont compris qu’ils retrouveraient les mêmes dans la pipeline. La cohérence est un point central.

Il tenait aussi à fournir aux développeurs des données de qualité. Par exemple, il voulait qu’ils puissent déterminer facilement si un paquet était adapté à un projet ou s’il valait mieux en trouver un autre. Or, le meilleur moyen d’y parvenir, c’est de s’appuyer sur les données. Lorsque les développeurs savent qu’ils ont accès à un outil comme Snyk Advisor et qu’ils peuvent ainsi consulter rapidement des indicateurs comme la popularité d’un paquet ou son problème le plus récent, ils appréhendent mieux la complexité. Craik Pyke explique qu’il s’agissait de l’une des missions les plus importantes de son rôle : fournir aux développeurs des données fiables en espérant qu’ils feront les bons choix.

Baliser le chemin

Ensuite, Craik Pyke a commencé à travailler sur la mise en place d’une infrastructure de développement commune. Pour ce faire, il a utilisé un référentiel d’artefacts commun (Artifactory, mais de nombreux autres font l’affaire). Son principal objectif était de faire en sorte que les développeurs récupèrent toujours leurs artefacts depuis le registre. Il s’agit d’un point absolument crucial dans une entreprise en hypercroissance, car une équipe de développeurs de plus en plus étoffée peut potentiellement se traduire par une infrastructure de plus en plus importante (et non encadrée). Mais il ne voulait pas pour autant que l’équipe de sécurité gêne le travail des développeurs. Ses membres expliquaient ainsi aux développeurs : « dirigez votre fichier de configuration habituel vers ce système d’artefacts, et si vous n’y trouvez pas ce que vous cherchez, le système s’en chargera pour vous. Il vous aidera. » Dans un premier temps, cette évolution a nécessité un peu de pédagogie auprès des intéressés. Mais une fois que tout le monde a accepté de récupérer ses artefacts depuis ce cluster unique, l’entreprise a pu voir ce qui se passait chez chacun et à quel moment, et quelles versions étaient utilisées.

L’équipe de Craik Pyke a choisi d’autoriser les développeurs à travailler en dehors de leur pipeline, mais dans ce cas, dès qu’ils essayaient de soumettre un pull request, leur demande échouait. La pipeline de développement réalisant les tests depuis GitHub n’était pas autorisé à récupérer des ressources depuis Internet, mais seulement depuis le référentiel d’artefacts. Ainsi, les développeurs ayant adopté dès le début le comportement attendu en utilisant le dépôt d’artefacts ne rencontraient aucun problème.

Comment avons-nous fait pour que les développeurs n’aient pas le sentiment d’être bloqués par la sécurité ? Nous avons adopté une approche positive. Plutôt que de manier le bâton, nous avons misé sur la carotte jusqu’au bout. Nous leur avons dit : « en accédant au référentiel unifié, vous ne risquez pas de tomber sur des paquets malveillants ou des licences inappropriées, car nous pouvons analyser toutes les ressources à mesure que vous les récupérez. Nous veillons ainsi à ce que vous ne fassiez pas d’erreur. » Les développeurs ont donc changé leur vision de la sécurité. D’adversaire, l’équipe de sécurité est devenue un interlocuteur à qui poser des questions et qui apporte des réponses. Nous sommes là pour aider, pas pour gêner.

Ambassadeurs de la sécurité : un rôle central

Si c’est bien l’équipe de Craik Pyke qui leur a montré le chemin, certains développeurs de SurveyMonkey sont peu à peu devenus de véritables ambassadeurs de la sécurité. Les plus expérimentés ont expliqué aux nouveaux arrivants le fonctionnement du référentiel d’artefacts, l’identification des signaux dans les pull requests et à qui adresser leurs questions. Pour Craik Pyke, « cela revient en gros à intégrer le support de niveau 1 dans les équipes de développeurs. » Il n’a pas mis en place de programme officiel d’ambassadeurs de la sécurité, tout simplement car les nouveaux membres de l’équipe intégraient d’eux-mêmes l’importance de la sécurité.

Lorsque les développeurs deviennent des auditeurs de la sécurité de leur propre code, l’équipe de sécurité peut les accompagner. Craik Pyke explique qu’avec un chemin balisé et un ensemble d’outils appropriés, et notamment les outils Snyk, qui facilitent la détection et la correction des vulnérabilités, l’équipe de sécurité peut déclencher des régénérations d’artefacts lorsque c’est nécessaire, sans gêner les développeurs.

Les données que nous obtenons de nos outils et de notre pipeline permettent véritablement aux développeurs de faire des choix intelligents.

Partager les responsabilités et les objectifs

Dans une culture « shift left » saine, les développeurs préfèrent gérer les exigences de sécurité dès le départ. La validation ainsi obtenue leur permet de réaliser plus rapidement les tâches générant de la valeur. L’équipe de sécurité ne va pas ordonner aux développeurs d’accomplir telle ou telle étape pour des questions de sécurité. Ce sont les développeurs qui vont consulter l’équipe de sécurité pour l’informer qu’ils ont repéré un problème en lien avec un paquet et lui demander s’ils peuvent le traiter. L’équipe essaie également de partager la responsabilité. Au lieu de rejeter la faute sur une personne en particulier lorsqu’une vulnérabilité passe entre les mailles du filet, elle résout le problème au plus vite et débat ensuite des leçons à tirer de cette expérience.

Soutenir les développeurs, c’est aussi leur permettre de s’épauler mutuellement. Lorsque l’équipe de Craik Pyke a déployé Snyk pour détecter les vulnérabilités, elle s’est assurée que ce déploiement ne soit pas bloquant dans GitHub. Au contraire, elle a permis à davantage de développeurs expérimentés d’encadrer leurs collègues plus jeunes pendant l’examen du code et des pull requests. Un développeur expérimenté peut par exemple expliquer : « Cette croix rouge veut dire qu’il y a un problème. Oui, techniquement, tu peux fusionner le code, mais il y a quand même un problème. » Ce processus n’a pas été imposé du jour au lendemain. L’équipe a plutôt misé sur la création d’une culture collaborative. Faire monter en puissance les outils de Snyk à un niveau adapté aux équipes de SurveyMonkey était la bonne approche.

Regardez la table ronde complète pour découvrir d’autres informations passionnantes sur la sécurité des développeurs.