Comment Datto a fait de la sécurité pensée pour les développeurs une réalité avec Snyk

Lorsque David McCheyne, ingénieur DevOps chez Datto, a présenté un plan pour amener progressivement l’entreprise à adopter une approche de la sécurité pensée pour les développeurs avec Snyk, il pensait qu’il faudrait un an à ses équipes pour valider le concept. Professionnel DevOps chevronné, David mesurait parfaitement l’ampleur du changement et était prêt à présenter progressivement la plateforme Snyk aux référents sécurité de Datto, sans imposer le processus.

C’était un excellent plan, qui a vite évolué. En quelques mois, toutes les équipes de développement de Datto avaient adopté Snyk. « Quelques semaines après le lancement, les développeurs échangeaient entre eux pour améliorer les choses, et ils ont commencé à venir me demander si leurs équipes pouvaient essayer [Snyk] aussi », explique-t-il. « Avant même que je m’en rende compte, presque par hasard, chaque équipe produit de Datto avait un référent sécurité qui avait déployé Snyk. »

À l’heure où développer rapidement des logiciels sûrs n’a jamais été aussi crucial, l’adoption presque sans difficulté par Datto d’une approche de la sécurité pensée pour les développeurs offre un modèle que presque toutes les entreprises peuvent suivre. Nous avons demandé à David de nous expliquer les priorités des équipes et ce à quoi elles doivent se préparer. Attention, divulgâchage : l’adoption rapide n’a pas été la seule surprise de David !

Commencez par obtenir l’adhésion

Une approche de la sécurité pensée pour les développeurs exige l’adhésion de tous, et notamment des développeurs. Selon David, c’est la partie la plus difficile de tout le processus. « Les développeurs veulent bien faire, mais ils doivent composer avec beaucoup d’autres priorités », explique-t-il. « Il y a toujours de nouvelles fonctionnalités, de nouvelles technologies, des mises à niveau des systèmes d’exploitation… toujours 12 choses différentes qui sollicitent l’attention d’un développeur. Et la sécurité n’a rien de séduisant ni d’enthousiasmant ; elle ne génère pas de grands bénéfices, sauf lorsqu’elle fait la une. »

L’astuce consiste à simplifier au maximum la tâche des développeurs. « Snyk permet aux développeurs de s’occuper de la sécurité tout en accomplissant d’autres tâches », explique-t-il. Comme les équipes d’ingénierie logicielle de Datto vivent au rythme des pipelines CI, l’ajout de Snyk à ces processus existants a demandé peu d’efforts et n’a pas perturbé les opérations courantes. Grâce à ce feu de signalisation supplémentaire, les développeurs pouvaient repérer immédiatement les dépendances à mettre à niveau, suffisamment tôt pour éviter de se retrouver au feu rouge. « Cela permet à nos développeurs de faire ce qu’il faut très facilement, sans empiéter sur le temps consacré au développement des produits. Snyk a très bien résolu ce problème pour nous. »

Autre avantage : la dette liée à la gestion des dépendances a considérablement diminué. La résolution des dépendances n’est la tâche préférée d’aucun développeur, mais son automatisation a complètement changé la donne chez Datto, explique David. La plupart des projets de Datto ne comptent que trois à cinq dépendances, mais certains en ont plus de 2 500. Cela représente beaucoup de vérifications si un développeur n’utilise pas la bonne version et ne s’en aperçoit qu’à la fin du processus. « Dans chaque pipeline CI de développeur et à chaque commit, un petit feu de signalisation supplémentaire est visible par tous et leur permet de traiter rapidement le problème de dépendance », explique David. Avec Snyk, les équipes de Datto « peuvent consacrer davantage de temps humain à des problèmes de sécurité applicative plus variés et plus importants, tout en se souciant beaucoup moins des dépendances ».

Adoptez une vision plus large de la sécurité

David se concentrait tellement sur les dépendances qu’il a été agréablement surpris de découvrir que Snyk pouvait aussi prendre en charge un autre processus chronophage : l’analyse des licences open source. « Dans beaucoup d’entreprises, l’analyse des licences open source est entièrement manuelle et implique les équipes juridiques et informatiques », explique David. C’était bien le cas chez Datto. Mais une fois Snyk intégré au pipeline CI, David a compris qu’il pouvait configurer dans Snyk les projets associés à des licences déjà vérifiées. Les équipes juridiques et informatiques « n’évoluent pas dans les mêmes environnements CI, car ce sont des équipes totalement différentes, mais le temps gagné sur l’analyse des licences grâce à Snyk a été un avantage étonnamment précieux pour nous ».

Misez sur la diversité des référents sécurité

Selon David, si les équipes de développement de Datto avaient un atout secret pour réussir leur transition vers une sécurité pensée pour les développeurs, c’étaient bien les référents sécurité. Le bouche-à-oreille autour de Snyk a incité des personnes de tous les services de l’entreprise à se porter volontaires pour contribuer à la culture de la sécurité. Mais avec ou sans cet engouement, il est important pour les entreprises d’élargir au maximum leur recrutement lorsqu’elles mettent en place un programme de référents sécurité, explique-t-il. « N’en faites pas un club secret de la sécurité », affirme-t-il sans détour. « L’objectif est que tout le monde contribue à la sécurité. Plus il y a de personnes impliquées et qui y réfléchissent, mieux c’est. »

David a vu des personnes issues de « secteurs inattendus » de Datto se porter volontaires pour devenir référents sécurité, dont beaucoup ne savaient pas exactement en quoi consistait ce rôle. Cela tient en partie à la culture de Datto, qui apprécie le concept de « guildes » et encourage les équipes transverses. « Nos référents sécurité bénéficient d’un cadre très structuré », explique-t-il, tout en soulignant qu’il est important d’adapter le programme à la culture existante de l’entreprise. « Il n’y a pas de solution universelle », précise-t-il. « Vous devez trouver comment intégrer un programme de référents sécurité à votre propre puzzle. »

Développez une solide culture DevOps

La surcharge de travail des développeurs est bien réelle et doit être prise en compte lors de la transition vers une sécurité pensée pour les développeurs, explique David. Mais une solide culture DevOps peut y remédier. Écoutez vos équipes DevOps et transmettez leurs commentaires aux personnes qui conçoivent les produits, conseille-t-il. Le plaidoyer des équipes DevOps en faveur des outils et de la charge de travail des développeurs est essentiel à la santé et à la réussite de l’organisation ; leurs préoccupations doivent être entendues. Les équipes DevOps doivent être prêtes à défendre leurs choix technologiques, en particulier lorsque ceux-ci risquent d’alourdir la charge de travail des développeurs. Toutes les entreprises veulent gagner en efficacité, mais si la direction ne comprend pas l’importance de la culture DevOps pour offrir une solide expérience de développement, la surcharge de travail et l’épuisement peuvent s’installer. Les équipes ont besoin de solutions qui leur permettent de faire facilement ce qu’il faut, comme Snyk, explique David.

Lancez-vous !

Le dernier conseil de David est tout simple : n’ayez pas peur d’essayer. Les préoccupations liées à l’adhésion, à la culture, aux coûts et à l’assistance sont légitimes, mais elles doivent être mises en balance avec l’importance de s’engager dès maintenant en faveur de la sécurité. « Il est facile de s’inquiéter des difficultés que pourrait représenter la mise en place d’une pratique de sécurité pensée pour les développeurs, et de se demander si elle sera adoptée ou appréciée », explique David. Mais si les équipes choisissent les bonnes technologies et les déploient judicieusement, les retours ne peuvent être que positifs. « Snyk a notamment très bien réussi à créer un produit qui améliore la vie des développeurs de façon modeste, mais significative. Grâce à lui, nous avons aujourd’hui une bien meilleure visibilité sur nos dépendances. »