Chanel développe ses propres applications en interne. Depuis 4 ans, la prestigieuse Maison veut en chasser les vulnérabilités et diffuse progressivement la culture DevSecOps auprès de ses développeurs.
Comme tous les géants du luxe, la Maison Chanel opère sa transformation digitale et dispose d’équipes de développement en interne pour ses sites et applications de e-commerce. Il y a quelques années, la célèbre marque s’est souciée de la sécurité des applications produites par ses équipes et a créé un poste de responsable de la sécurité applicative.
C’est Rémi Lavedrine qui a été chargé de la sécurité de ces applications maison : « il y a beaucoup de développeurs au sein d’une entreprise dont le logiciel n’est pas le cœur de métier. Néanmoins, aujourd’hui, lorsque l’on produit du logiciel, on se doit de faire de la sécurité. Les développeurs ont beau faire leur maximum, il y a des bugs dans le code produit et mon rôle est d’être certain que l’on va prendre en charge ces vulnérabilités le plus en amont possible ».
Avant la nomination d’un responsable dédié, la sécurité applicative dépendait alors du bon vouloir des développeurs, sachant que ceux-ci étaient plus ou moins engagés par cette problématique. Ils ne disposaient pas encore d’outils et étaient peu ou pas formés. Difficile dans ces conditions d’évaluer la dette cyber du parc applicatif.
Dans ce cadre, Rémi Lavedrine lance le déploiement de la solution Veracode, mais surtout initie un programme AppSec pour instiller les concepts Secure DevOps dans les équipes et les process : « plus un problème de sécurité est pris en amont, moins il est compliqué pour le développeur de le résoudre et moins c’est cher pour l’entreprise ».
Le responsable estime qu’il y a un rapport de 1 pour 30, entre détecter une vulnérabilité en phase de développement et en production : « mon rôle est de détecter les vulnérabilités le plus en amont possible et cela passe par des outils, des processus et des gens. Mon rôle est d’organiser toute cette stratégie de sécurité et ce programme AppSec ».
Chanel s’est appuyé sur Devoteam pour son programme DevSecOps
Chanel a fait appel à Devoteam pour l’appuyer dans la mise en place de cette démarche. Avant même de se lancer dans la mise en place de nouveau processus, l’équipe de l’ESN a commencé par auditer le fonctionnement des équipes de développement de son client : « on commence par un audit de maturité, dans le cadre duquel on interviewe les membres des différentes équipes, afin de voir ce qu’elles ont en commun et les pratiques qui peuvent être différentes les unes des autres », résume Laurent Lajugie, leader de l’offre DevSecOps de Devoteam.
Cela fait, poursuit-il, « on identifie ce qui marche, ce qui ne marche pas et quelles ont été les initiatives et les résultats obtenus. On regarde aussi toute la partie documentaire, tout ce qui est tracé, et quelle documentation dispose un nouvel arrivant dans l’entreprise, sur quoi il va être formé ».
Cette première phase d’analyse a permis d’élaborer une roadmap à court, moyen et long terme en fonction des priorités fixées par Chanel et de rendre cette transition vers le Security by Design le plus fluide possible. « Il est très important de détecter les vulnérabilités, d’évaluer où l’on en est dans la démarche, mais l’objectif final reste de réduire le niveau de risque, le nombre de vulnérabilités et d’améliorer le niveau de maturité et le niveau de sécurité », ajoute Laurent Lajugie.
Les applications critiques dans un premier temps
Le programme de transformation est lancé sur un périmètre restreint, sur les applications jugées les plus critiques avant de passer à l’échelle dans un deuxième temps.
Rémi Lavedrine estime qu’il faut savoir capitaliser sur les obstacles rencontrés pour éviter aux autres entités de s’y heurter aussi. Ce qu’il considère ainsi comme une erreur fut de constituer une équipe d’experts en cybersécurité chargés d’aider les équipes de développement : « dans les faits, cette approche ne fonctionne pas, car les équipes de développement ont une certaine réticence à onboarder des gens de la sécurité. Ils considèrent qu’ils vont mettre le nez dans leurs affaires, soulever des loups… »
Rémi Lavedrine change alors d’approche. Les spécialistes en gestion de projet et technologie rendent toujours des comptes au responsable de la sécurité, mais sont détachés au sein des équipes de développement : « ils font pleinement partie de ces équipes et se plient aux rituels des équipes. En faisant pleinement partie des équipes, ils apprennent des choses sur la façon dont fonctionnent réellement les équipes de développement. C’est comme cela que l’on s’aperçoit que certains processus sont réalisés d’une certaine façon par les uns et différemment par les autres, que certains risques peuvent être pris, car ils sont mal compris ». Pour le responsable, les outils et l’organisation sont les moyens de faire baisser de manière très significative la dette de sécurité.
« La clé est d’avoir des gens qui sont engagés dans la sécurité, mais qui sont détachés auprès des équipes de développement. C’est un game changer dans la capacité à anticiper les problèmes de sécurité. »
Rémi Lavedrine CCISO, Head of Application Security, Chanel
Côté outillage, le déploiement de la solution Veracode qui avait été initié se voit accéléré. Pour Laurent Lajugie, la partie la plus importante d’une transformation DevSecOps reste les collaborateurs : « on forme et on accompagne les personnes, mais au-delà d’une formation classique, surtout, on se met à leur place. Dans un premier temps on assume ce rôle de Security Champion à leur place pour leur montrer que ce n’est pas si compliqué que cela et que nous sommes derrière eux pour les aider. Petit à petit, ils deviennent autonomes, ils acquièrent les bons réflexes et nous pouvons commencer à nous retirer et nous occuper d’autres équipes ».
La position de l’expert est d’impacter au minimum les habitudes de travail des développeurs : « s’ils ont l’habitude d’utiliser tous les outils depuis leur IDE, nous ferons en sorte qu’ils n’aient pas à ouvrir Veracode. On ne vient pas modifier leur façon de travailler, mais nous adaptons les processus à leur quotidien de façon à ce que ce soit le plus simple pour eux de prendre en charge la sécurité ».
L’autre volet clé reste la mise en place de processus pour bien définir qui fait quoi dans la chaîne CI/CD vis-à-vis de la cybersécurité.
La sécurité doit pleinement faire partie de l’assurance qualité
Pour Rémi Lavedrine, la sécurité applicative ne doit pas être considérée comme quelque chose de différent de la qualité du logiciel et il faut faire entrer le programme de sécurité dans l’assurance qualité : « une vulnérabilité critique n’est rien d’autre qu’un bug majeur et doit être traitée de la même façon. Si demain, le tunnel d’achat ne fonctionne plus, le management va demander à ce que le problème soit traité très rapidement. Il y a des process en place pour traiter ce type de problème très vite. Si on arrive à intégrer la sécurité dans ce même type de process, une vulnérabilité critique détectée très en amont sera corrigée facilement ».
« Le développeur qui a développé le code et à qui on demande de revenir dessus 3 mois plus tard va avoir besoin de plus de temps pour se le réapproprier ».
Rémi LavedrineCCISO, Head of Application Security, Chanel
Un autre point très important pour le responsable est de corriger rapidement les vulnérabilités qui sont détectées dans le code. « Plus on met de temps à détecter une vulnérabilité, plus elle est complexe à être corrigée, car le développeur qui a développé le code et à qui on demande de revenir dessus 3 mois plus tard va avoir besoin de plus de temps pour se le réapproprier ».
L’équipe se projette maintenant dans la seconde phase du programme, la diffusion du DevSecOps auprès des autres équipes de développement, et assure le passage à l’échelle de DevSecOps auprès de toutes les équipes. « Une fois que les équipes sont onboardées, nous ne gérons plus que 10 % des problèmes », indique Laurent Lajugie. Ainsi, « nous pouvons ensuite nous appuyer sur eux pour répandre la bonne parole et acculturer les autres équipes, voire même d’autres entités ».
L’idée est bien que les développeurs sont les plus légitimes pour promouvoir ces bonnes pratiques auprès des autres développeurs que des membres de l’équipe sécurité elle-même. Ceux-ci peuvent désormais s’appuyer sur les guides, les programmes de formation, les outils et les processus qui ont déjà été mis en place.
