Comment Snyk fait de l’expérience développeur une priorité

Le changement de contexte peut être le pire ennemi de la sécurité. Les pratiques de sécurité actuelles nécessitent l’adhésion des développeurs. Lorsque les équipes de sécurité leur demandent de s’écarter de leurs workflows habituels pour corriger des problèmes, ils sont beaucoup moins susceptibles d’adopter ces pratiques.

Pour réellement permettre aux développeurs de détecter et de corriger les vulnérabilités dans leur code, les équipes de sécurité doivent aller encore plus loin dans l’intégration de la sécurité en amont. Il ne suffit pas de fournir des outils faciles à utiliser et de les accompagner de formations. Si les développeurs doivent toujours interrompre leur workflow pour effectuer des tâches liées à la sécurité, cela augmente leur charge cognitive. Ils manquent souvent de temps ou de ressources pour ajouter une tâche de plus à une liste déjà bien remplie.

Pour relever ces défis, Snyk lance de nouvelles fonctionnalités qui enrichissent nos solutions conçues pour les développeurs et permettent aux équipes de sécurité de continuer à s’adapter aux nouvelles réalités des cycles de développement actuels. Nous avons récemment donné à nos utilisateurs un aperçu de ces nouveautés lors de notre dernier SnykLaunch, désormais disponible à la demande. Dans cet article, nous vous présentons les nouveautés qui améliorent directement l’expérience développeur et expliquons leur importance pour les équipes d’aujourd’hui.

Le coût du changement de contexte

Les développeurs passent une bonne partie de leur temps à trois endroits : leur IDE, la CLI et leur SCM. Il peut sembler simple de recevoir une alerte de sécurité concernant un projet en cours et de passer sur une autre plateforme pour résoudre le problème, mais, en réalité, ça ne l’est pas. Ce changement de contexte éloigne les développeurs de leurs habitudes de travail et ajoute des étapes au développement logiciel. Il perturbe leur productivité et les oblige à passer d’un système à l’autre pour effectuer des tâches liées à la sécurité.

Les développeurs écrivent l’essentiel de leur code dans leur IDE, qu’il s’agisse de code écrit à la main, généré par l’IA générative ou d’une combinaison des deux. Ils créent des branches ou des forks, envoient leur code progressivement vers leur SCM et, lorsqu’ils sont prêts, ouvrent une « pull request » (PR). Les pull requests sont conçues pour faciliter la collaboration et la revue de code. Interrompre ce processus en obligeant les développeurs à quitter leur workflow SCM pour traiter des problèmes de sécurité leur impose une tâche imprévue et brise leur élan, à l’encontre d’un workflow de PR efficace. C’est comme si l’on ajoutait par surprise un élément à votre liste de tâches alors que vous pensez avoir presque terminé.

Ce manque de coordination entre les équipes de développement et de sécurité nuit aux efforts DevSecOps. Les équipes de sécurité se demandent souvent pourquoi davantage de développeurs n’adoptent pas leurs outils, tandis que les développeurs peuvent résister aux interruptions de leur workflow causées par des tâches imprévues. Tout le monde y perd.

Deux piliers de l’expérience développeur

Plutôt que de demander aux développeurs de se détourner de leur travail pour traiter les problèmes de sécurité, les équipes de sécurité doivent les rejoindre dans les outils qu’ils utilisent déjà. Deux principes fondamentaux peuvent les y aider :

1. Donner aux développeurs des informations dans le contexte où ils travaillent

Pour corriger efficacement les problèmes de sécurité dans leur code, les développeurs ont besoin d’un minimum de contexte. Ils doivent notamment savoir pourquoi une ligne donnée a été signalée comme vulnérable et quelles modifications peuvent corriger la vulnérabilité. Cependant, les équipes de sécurité ne peuvent pas s’attendre à ce que les développeurs parcourent une documentation générique ou suivent des tutoriels sur une plateforme de sécurité pour résoudre le problème. Elles doivent leur fournir des ressources pédagogiques concises, avec quelques éléments de contexte et des conseils de correction, ni plus ni moins.

2. Réduire les frictions et perturber le moins possible les workflows

Snyk aide déjà les développeurs à détecter et à corriger les vulnérabilités directement dans leurs IDE. Sachant qu’ils passent aussi beaucoup de temps dans leur SCM, Snyk étend ses outils conçus pour les développeurs en intégrant des informations de sécurité aux workflows de PR dans les SCM. Les développeurs peuvent ainsi recevoir des retours sur la sécurité en toute simplicité, dans les outils qu’ils utilisent au quotidien.

Les nouvelles fonctionnalités de PR de Snyk pour une meilleure expérience développeur

Notre expérience auprès des équipes de développement et notre accompagnement des développeurs dans l’intégration de la sécurité à leurs IDE nous ont appris que le meilleur endroit pour intégrer la sécurité est dans les outils qu’ils utilisent déjà. Désormais, lorsqu’un développeur clique sur le bouton « créer une PR », les vérifications de PR de Snyk (disponibles de manière générale pour Snyk Open Source et en accès anticipé pour Snyk Code) peuvent effectuer une revue de sécurité du code directement dans les workflows de PR habituels.

Une fois l’analyse PR Check terminée, notre nouvelle fonctionnalité « résumé des problèmes » publie un commentaire dans le SCM, directement dans le workflow de PR des développeurs, avec une synthèse des résultats de sécurité. Ces données récapitulent les résultats par niveau de gravité et fournissent aux développeurs des liens directs pour examiner et corriger les problèmes.

Nous proposons également des modèles de PR personnalisables, qui permettent aux équipes de personnaliser les PR générées par Snyk. Ces modèles personnalisables alignent les pull requests générées par Snyk sur les normes, les pratiques et les préférences de communication propres à votre organisation. Vous pouvez définir le titre et la description, choisir les détails de sécurité à partager et même ajouter les informations de ticket JIRA, afin de répondre aux attentes des développeurs. En adaptant nos fonctionnalités aux besoins de votre organisation, vous intégrez encore plus naturellement le workflow aux processus existants des développeurs.

Pour en savoir plus sur ces nouvelles fonctionnalités de pull request, regardez la dernière présentation SnykLaunch.