Comment Mulesoft favorise une culture centrée sur les développeurs et la sécurité intégrée dès le début avec Snyk

Depuis une dizaine d’années, l’intégration de la sécurité dès le début du cycle de développement est un sujet très présent, mais de nombreuses organisations peinent encore à la concrétiser. Beaucoup d’idées reçues circulent sur ce que signifie cette approche et sur la manière dont les équipes de développement peuvent prendre en charge la sécurité sans perturber leurs workflows existants. Par exemple, de nombreuses équipes ont tendance à transmettre les problèmes de sécurité aux développeurs plus tôt dans le cycle de vie du développement logiciel (SDLC), sans leur fournir le contexte ni les outils nécessaires pour les corriger efficacement.

L’équipe de Mulesoft voulait faire autre chose que de simplement envoyer des alertes de sécurité aux développeurs. Elle était convaincue que la réussite d’une véritable approche DevSecOps repose sur la priorité accordée à l’expérience des développeurs. Mais pour concrétiser ces objectifs, Mulesoft devait s’engager dans une démarche s’appuyant sur les bonnes solutions et les bons processus.

Lors d’une récente discussion informelle, Clinton Herget, Field CTO chez Snyk, et Martin Adolfi, Sr. Engineering Manager chez Mulesoft, ont évoqué le parcours DevSecOps de Mulesoft. Ils ont exploré la véritable définition de la sécurité des développeurs pour les organisations actuelles, qui évoluent à un rythme soutenu, ainsi que les défis et les réussites de Mulesoft dans la mise en œuvre de ses objectifs d’intégration de la sécurité dès le début.

Le défi de Mulesoft : concrétiser l’intégration de la sécurité dès le début

Quand Adolfi et son équipe ont commencé à approfondir leurs initiatives DevSecOps, ils avaient une vision précise de l’intégration de la sécurité dès le début et de ce qu’elle ne devait pas être. L’équipe a constaté un décalage entre les attentes en matière de sécurité et l’état d’esprit habituel des développeurs. Adolfi a décrit cette approche comme « envoyer la sécurité à gauche » plutôt que de l’intégrer dès le début : on transmet des alertes ou des rapports aux développeurs sans leur donner davantage de contexte ou de conseils, puis on s’attend à ce qu’ils règlent le problème. Au final, cette méthode leur fait perdre du temps et de l’énergie mentale, les oblige à changer de contexte et les détourne de leur état de concentration et de productivité. Elle les éloigne de ce qu’ils aiment faire — coder et innover —, ce qui réduit leur satisfaction au travail et crée des tensions entre les équipes de développement et de sécurité.

Pour motiver les développeurs à réussir en matière de sécurité et, à terme, à devenir des ambassadeurs de la sécurité, il faut commencer par leur proposer la voie la plus simple. Selon Adolfi, la clé consiste à leur donner les moyens de corriger les problèmes dans le cadre de leurs boucles de rétroaction existantes. Il explique : « Si le problème devient un ticket, il est déjà trop tard… Il faut créer des outils qui s’intègrent dans le workflow des développeurs, au lieu de dire : “Nous avons un nouveau tableau de bord ou un nouveau rapport, et vous devez consulter cet outil pour trouver les informations dont vous avez besoin”… [En tant que développeur], on m’interrompt constamment alors que je veux faire quelque chose qui me plaît et qui m’intéresse. Je dois consulter sept sources de données différentes pour faire mon travail. »

L’équipe savait qu’elle voulait intégrer les boucles de rétroaction de sécurité dans les workflows existants des développeurs, mais devait relever plusieurs défis pour y parvenir.

Tout d’abord, elle devait tenir compte des commentaires des développeurs, qui estimaient qu’il y avait « trop de bureaucratie » dans le processus de sécurité des applications. Les équipes de développement de Mulesoft ressentaient la pression liée à la maintenance des projets existants, qui exigeait des correctifs réguliers, ainsi qu’au respect des exigences de conformité et des SLA dans les nouvelles applications. Elles avaient besoin d’une approche de sécurité qui n’alourdirait pas cette bureaucratie.

De plus, les pipelines des équipes de développement étaient très différents les uns des autres, mais les développeurs appréciaient cette liberté et ne voulaient pas y renoncer. Cette diversité de langages, de frameworks et de microservices compliquait la mise en place d’un processus de sécurité cohérent à l’échelle de toute l’organisation.

Les réussites de Mulesoft en DevSecOps

Pour relever ces défis, Mulesoft avait besoin d’un partenaire de sécurité qui donne la priorité aux développeurs. L’équipe a choisi la plateforme Snyk, car elle correspondait étroitement à ses objectifs DevSecOps.

Adolfi explique : « Snyk partage notre approche : intégrer la sécurité dès le début, apporter davantage de valeur, fournir des informations utiles et indiquer aux développeurs comment corriger les problèmes, en leur donnant toutes les informations nécessaires pour comprendre l’impact et le niveau de criticité — tout cela. »

Comme Snyk s’intègre aux différents environnements natifs des développeurs et fournit instantanément des commentaires et des suggestions de correction, Adolfi et son équipe ont réussi à simplifier le processus de détection et de correction des vulnérabilités pour les développeurs de Mulesoft.

Adolfi explique : « La principale raison pour laquelle l’équipe chargée de l’expérience des développeurs s’est intéressée à Snyk plutôt qu’au reste de notre stack technologique, c’est que Snyk est la solution la plus proche des développeurs. »

Snyk + Mulesoft : les prochaines étapes

À mesure que l’équipe de Mulesoft poursuit la sécurisation du SDLC avec une approche DevSecOps, elle continuera de s’appuyer sur le principe de l’intégration de la sécurité dès le début en donnant davantage de moyens aux développeurs. Pour cela, il faut fournir aux équipes de développement les outils et les processus dont elles ont besoin pour corriger efficacement les vulnérabilités en temps réel et limiter autant que possible les changements de contexte.

Pour la prochaine étape de son parcours de développement, l’équipe de Mulesoft prévoit d’intégrer davantage d’outils d’IA à ses pipelines. Elle voit des possibilités d’utiliser l’IA pour écrire et relire du code.

Pour en savoir plus sur le parcours de Mulesoft en matière de sécurité des développeurs et ses réussites DevSecOps, écoutez l’intégralité de la conversation avec Adolfi et Herget.

Play Video: How Mulesoft Achieved Developer Security at Scale