Skip to main content

Comment REI a instauré une culture DevSecOps et comment Snyk l’a accompagnée

Écrit par
Headshot of Brian Piper

Brian Piper

feature customer rei

27 février 2024

0 minutes de lecture

Il y a quelques années, REI s’est lancée dans une transformation numérique et une migration vers le cloud, en transférant ses environnements de développement sur site vers AWS. Mais, lorsque les équipes de développement de REI ont entamé cette transition, leurs homologues de la sécurité ont remarqué que la sécurité des applications ne suivait pas. REI s’est alors engagée dans une autre démarche : trouver les bons outils de sécurité et faire évoluer sa culture pour réussir en matière de sécurité des applications. 

Dan Ngo, ingénieur principal en sécurité, ingénierie de la cybersécurité et gestion des risques chez REI, et Clinton Herget, directeur technique de terrain chez Snyk, ont échangé lors d’une session AWS Re:Invent 2023 sur la manière dont l’équipe de REI a instauré une solide culture de la sécurité dans ses équipes de développement. Découvrez leur parcours et regardez la vidéo complète ci-dessous. 

Pourquoi REI a décidé de mettre en place un programme de sécurité des applications

À l’arrivée de Dan chez REI, l’entreprise traversait une période de transformation numérique, notamment avec une migration vers le cloud. À cette époque, la sécurité était largement exclue des processus de développement et se concentrait sur d’autres sujets, comme la sécurité des terminaux ou des e-mails. Il existait quelques initiatives de sécurité des applications, mais elles consistaient surtout en différentes approches adoptées par les équipes de développement pour sécuriser leurs applications. Ces équipes comptaient principalement sur quelques référents en sécurité pour prendre les choses en main. Or, ces référents avaient des niveaux d’expérience variables en matière de pratiques de sécurité, ce qui entraînait des incohérences dans toute l’organisation.

À son arrivée, Dan a demandé aux développeurs ce qu’ils faisaient en matière de sécurité. Ils lui ont expliqué qu’ils utilisaient quelques outils pour générer des rapports de sécurité, mais qu’ils consultaient rarement les résultats. 

Selon Dan : « Certains ingénieurs et développeurs étaient sensibilisés à la sécurité et avaient mis en place des analyses de sécurité pour des raisons de conformité. Mais ils n’en tiraient pas vraiment de bénéfices. »

Dan et son équipe devaient poser des bases solides en matière de sécurité, capables d’évoluer au rythme de leurs efforts de modernisation des applications. Ils savaient que ces fondations devaient reposer sur la bonne combinaison d’outils, de culture et de processus. Leur objectif ultime était de déplacer la sécurité vers la gauche et d’impliquer les développeurs et les ingénieurs dans leurs initiatives de sécurité, afin de déployer une approche DevSecOps dans toute l’organisation. 

Comment REI utilise les outils Snyk

Dans le cadre de leur initiative visant à établir des relations solides avec les autres équipes, Dan et son équipe savaient qu’ils devaient choisir les bons outils pour détecter et corriger les vulnérabilités. Après avoir testé différents outils, ils se sont tournés vers Snyk. Les développeurs ont apprécié la visibilité sur les vulnérabilités open source offerte par Snyk Open Source, ainsi que les suggestions de correction de code de Snyk Code. L’équipe d’ingénierie de plateforme a également privilégié Snyk, car son intégration avec les outils existants de REI et l’environnement cloud AWS sous-jacent était la plus fluide. 

Conseils de REI pour instaurer une culture DevSecOps

En favorisant ce partenariat entre ingénierie et développement, l’équipe de Dan a découvert des méthodes efficaces, mais aussi d’autres qui ne l’étaient pas. Elle a finalement dû faire évoluer la culture de l’entreprise pour obtenir l’adhésion des équipes et les résultats de sécurité recherchés. 

Voici trois enseignements majeurs tirés de l’expérience de Dan dans la mise en place de cette culture avec les outils Snyk.

Comprendre en profondeur les priorités des autres équipes et instaurer un climat de confiance

Au début de sa démarche de sécurité, REI a tenté de déployer rapidement un nouvel outil d’analyse statique du code sans prendre le temps de comprendre le point de vue des développeurs. Le déploiement ne s’est pas bien passé. Dan explique que les développeurs ont résisté à l’outil, car il ne s’intégrait pas à leurs pipelines existants. Cela a créé de nombreuses tensions entre les deux équipes.

Après avoir recueilli des commentaires, l’équipe de Dan a compris qu’elle devait travailler avec les équipes de développement et d’ingénierie, et non contre leurs flux de travail existants. Elle a examiné en détail les plateformes et les équipes en place chez REI, puis a cherché à adopter des outils et des processus compatibles avec ceux-ci. 

Pour vraiment comprendre le point de vue de ces autres équipes, Dan a passé une grande partie de son temps au sein de l’équipe d’ingénierie de la fiabilité des sites, afin de se familiariser avec ses processus et ses priorités.

« J’ai contribué au code, appris comment fonctionnent les microservices et compris comment les ingénieurs en infrastructure travaillaient. Ensuite, il a fallu instaurer un climat de confiance, puis leur présenter davantage de concepts de sécurité. »

Faire de l’amélioration continue une priorité

Au fil de la conversation, Dan a évoqué plusieurs situations où son équipe a essayé quelque chose de nouveau, commis quelques erreurs, puis en a tiré des leçons. Au lieu d’attendre la perfection dès le départ, son équipe a choisi de commencer quelque part, puis d’améliorer les processus au fil du temps.

Pour illustrer sa volonté de s’améliorer en continu, son équipe a proposé des permanences de questions-réponses lors de l’introduction de Snyk. Ces échanges ouverts et les alertes de Snyk ont révélé que les développeurs ne pouvaient pas corriger eux-mêmes bon nombre des problèmes détectés par les analyses de sécurité. En effet, ces vulnérabilités se trouvaient dans une bibliothèque appelée CRAMPON, gérée par l’équipe d’ingénierie de plateforme. Certains développeurs utilisaient des versions obsolètes de ce framework. L’équipe de Dan a donc pu apporter des améliorations.

« Nous avons maintenant une politique de dépréciation, explique Dan. Nous avons un SLA. Nous travaillons également à définir la version minimale du framework CRAMPON et à communiquer cette information aux développeurs, afin qu’ils sachent qu’ils doivent utiliser une version minimale spécifique de nos outils internes. »

Définir la responsabilité des corrections et l’attribuer

Dans le cadre de son approche globale et axée sur l’action en matière de sécurité des applications, Dan souhaitait également trouver comment gérer le code hérité. Pour l’équipe, l’essentiel était de définir clairement quelles équipes étaient responsables de chaque élément logiciel hérité.

En décomposant la majeure partie de leur monolithe, l’équipe a pu déterminer qui était responsable de la plupart du code hérité. Snyk l’a aidée à identifier les dépendances. Aujourd’hui, l’équipe de sécurité sait clairement qui est responsable de chaque partie du code et peut coordonner les corrections avec les équipes concernées. Pour les éléments de code et les services qui restent dans le monolithe hérité et dont la responsabilité n’est pas clairement attribuée, l’équipe de sécurité traite directement les problèmes associés avec Snyk. Cela renforce le respect des développeurs et les incite à examiner eux-mêmes les problèmes. 

Les réussites de REI en matière de sécurité des applications 

Grâce à leurs choix de processus et d’outils, Dan et son équipe collaborent désormais beaucoup plus étroitement avec les équipes de développement et d’ingénierie de plateforme. Alors que le programme continue de gagner en maturité, Dan affirme que son principal objectif est de permettre aux développeurs de contextualiser et de comprendre les vulnérabilités des applications, puis de hiérarchiser et de mettre en œuvre les corrections dans le respect des SLA définis par REI, notamment du délai moyen de correction (MTTF). Snyk l’aide à atteindre cet objectif en détectant les vulnérabilités tôt dans le pipeline et en fournissant aux développeurs les ressources nécessaires pour les corriger rapidement. 

« Voir des développeurs déployer un correctif pour notre application parce que Snyk a signalé un problème est un très bon signe : nous sommes sur la bonne voie pour mettre en place un processus robuste et instaurer une relation de confiance entre les équipes de sécurité et de développement. » 

Regardez ci-dessous la présentation AWS Re:Invent pour en savoir plus sur notre partenariat avec REI. Si vous souhaitez essayer la plateforme de sécurité de Snyk conçue pour les développeurs, vous pouvez également créer un compte Snyk gratuit directement depuis AWS Marketplace ou directement depuis l’application Snyk. 

Vidéo : AWS re:Invent 2023 - Comment REI a instauré une culture DevSecOps dès le départ

AWS re:Invent 2023 - How REI built a DevSecOps culture from the start (DOP103)


Lire la suite

illustration hero ai
Blog

PHP corrige deux vulnérabilités RCE critiques exploitables sans authentification (CVE-2026-109618, CVE-2026-109619) : mettez à jour dès maintenant

Deux vulnérabilités critiques dans le cycle de traitement des requêtes de PHP peuvent permettre l’exécution de code à distance sans authentification. Passez à une version corrigée ou installez un correctif rétroporté par votre fournisseur pour les versions antérieures.

blog feature ai lilac
Blog

Transformez votre backlog de vulnérabilités en pull requests grâce à la remédiation agentique

Evo Remediation Agent est désormais disponible en aperçu ouvert et apporte la résolution automatisée des dépendances à Evo Agentic AppSec. Les équipes AppSec peuvent désormais lancer des campagnes de remédiation continues

AI Background min crop
Blog

L’IA fait surgir tous les risques que vous avez acceptés : sept enseignements du panel de sécurité de l’IA sans filtre

L’IA rend les attaques moins coûteuses et plus rapides, exposant des risques déjà présents dans les organisations. Quatre responsables de la sécurité expliquent pourquoi une défense à la vitesse des machines et une remédiation accélérée sont désormais indispensables.