Interviews d'experts - épisode #1 : DevSecOps

“La sécurité ne doit plus être perçue comme une contrainte ou un contrôle imposé en fin de cycle, mais comme une partie intégrante de la création de valeur.”

– Marie Bisault, experte sécurité

portrait de Marie Bisault

Lors cette série d’interviews, OCTO vous propose un aperçu des sujets à considérer dans votre trajectoire des mois à venir. Aujourd’hui, Marie Bisault, experte sécurité, nous parle du mouvement DevSecOps.

Qu’est-ce que DevSecOps par rapport aux pratiques de sécurité historiques ?

DevSecOps, c’est avant tout une approche qui consiste à intégrer la sécurité à chaque étape du développement logiciel.

Avant, la sécurité se faisait de manière traditionnelle, avec un modèle en cascade ou en cycle en V, où le RSSI intervenait principalement en début et en fin de projet. Aujourd’hui, avec l’essor de l’agilité et du DevOps, on ne peut plus se contenter d’une vérification ponctuelle à posteriori. Il faut penser à la sécurité de manière continue et intégrée.

On entend souvent ce terme utilisé comme buzzword mais, pour moi, il s’agit de repenser entièrement le modèle de sécurité. Il ne s’agit plus de se dire « je vais ajouter quelques contrôles de sécurité ici et là », mais de concevoir dès le départ une architecture et un processus de delivery dans lesquels la sécurité est au cœur des gests, pour répondre à la cadence imposée par le marché et aux exigences d’équipes multidisciplinaires. C’est une réponse à la nécessité de s’adapter à un environnement où l’écosystème demande une réactivité et une adaptabilité sans précédent.

Qu’implique DevSecOps vis-à-vis de l’organisation ?

Adopter DevSecOps, ce n’est pas simplement installer de nouveaux outils ou ajouter des étapes supplémentaires à un processus existant, c’est transformer entièrement la manière dont l’organisation aborde la sécurité. Cela implique de casser les silos traditionnels entre les équipes de développement et celles de sécurité, de rapprocher les experts de ces deux mondes pour que chacun comprenne et partage la responsabilité de livrer un logiciel sécurisé.

La sécurité ne doit plus être perçue comme une contrainte ou un contrôle imposé en fin de cycle, mais comme une partie intégrante de la création de valeur. Il faut instaurer un dialogue constant, repenser les rôles et encourager une culture commune qui responsabilise chaque membre de l’équipe. Pour moi, il s’agit de passer d’un mode de contrôle strict à une approche collaborative, où l’analyse des risques et la compréhension des enjeux sont partagées, pour mieux s’adapter aux défis actuels et aux nouvelles méthodes de développement.

Quels outils et méthodologies peuvent faciliter le DevSecOps ?

Dans un environnement agile, il est indispensable de mettre en place dès le début des outils de test et d’analyse de la sécurité. Par exemple, l’utilisation de SAST permet d’effectuer une analyse statique du code, tandis que les DAST offrent une analyse dynamique, et les SCA se concentrent sur l’évaluation des dépendances logicielles. Cela dit, il ne faut pas simplement accepter les résultats de ces outils car ils ne mettent pas les vulnérabilités ciblées en perspective de l’analyse de risque du produit.

Et au-delà de ces outils, il est essentiel d’adopter des méthodologies adaptées. Par exemple, en intégrant des pratiques telles que les « evil user stories » et la définition de critères d’acceptation sécurisés dans le backlog, on inclut les risques dans le flux de delivery, ce qui change la façon de les identifier mais aussi de les traiter. Ces méthodes permettent de sensibiliser les équipes dès le départ et de créer une dynamique d’amélioration continue. Il y a d’ailleurs un terme dédié sur l’intégration au plus tôt de la sécurité dans le design : Shift Left On Security.

Shift Left On Security

La première occurrence d’un Shift Left on xxx est apparue avec l’article Shift Left on Testing de Larry Smith en 2001. En sécurité, le concept est le même : à quoi bon faire l’inspection des travaux finis quand on peut mieux prendre en compte les enjeux dès le design ? C’est quasiment un synonyme de DevSecOps.

L’idée est de faire évoluer les mentalités : concevoir avec la sécurité, apprendre des erreurs, corriger petit à petit et éviter de simplement accumuler des listes de contrôles sans comprendre leur finalité ou les mettre en perspective des risques propres au produit. Ce n’est donc pas seulement ajouter des outils dans une pipeline, mais bâtir un processus qui responsabilise les développeurs et qui intègre la sécurité de manière organique, en s’appuyant sur des pratiques éprouvées et adaptées aux besoins spécifiques de chaque projet.

Quel rôle pour la GenAI ?

La GenAI pourrait, en théorie, jouer un rôle intéressant en aidant à détecter certaines failles de sécurité ou en optimisant l’analyse des vulnérabilités. Cela dit, il est important de ne pas croire que l’IA puisse remplacer la réflexion et l’expertise humaine. Même avec des outils basés sur l’intelligence artificielle, la compréhension des risques et la culture de sécurité restent fondamentales.

L’IA peut venir en complément, en accélérant certains processus ou en proposant des pistes d’amélioration, mais elle ne doit pas faire oublier que la sécurité repose avant tout sur une analyse fine et contextuelle. Même si des solutions de GenAI peuvent améliorer l’efficacité opérationnelle, elles ne sauraient substituer l’implication quotidienne des équipes et la réflexion stratégique nécessaire pour adapter la sécurité aux enjeux métiers spécifiques.

Pour ne pas rater les futures interviews, suivez notre blog et nos annonces sur LinkedIn.