DevSecOps : buzzword ou réalité ?

Plus qu'un simple ensemble d'outils et de processus, le DevSecOps représente un changement fondamental de culture d'une organisation. De quoi s'agit-il en pratique ?

Ces dix dernières années, le DevSecOps est devenu un buzzword dans l'industrie de la tech. Mais déjà auparavant son rôle permettait de résoudre un problème persistant : des workflows cloisonnés entre les équipes DevOps et de sécurité, qui affaiblissent la posture de sécurité d'une organisation et ralentissent les cycles de développement logiciel. Aujourd’hui, l'émergence accélérée du DevSecOps peut être attribuée à son efficacité à briser ces barrières.

Pour de nombreuses organisations, la sécurisation de l'infrastructure et des applications était historiquement perçue par les équipes de développement comme opérant à l'intérieur d'une tour d'ivoire. Les pratiques, les outils et les workflows de sécurité étaient isolés du développement et des opérations. Les développeurs considéraient souvent les pratiques de sécurité comme des obstacles qui ralentissent leurs projets, qui plus est survenant souvent dans une phase tardive, nécessitant des changements profonds à l’approche de la release. De même, les ingénieurs en sécurité n'avaient aucune vision ou compréhension des workflows de développement ou de ce qui était exactement déployé dans les environnements de préproduction et de production.

Pourquoi DevSecOps ?

Au début de ma carrière, j’ai travaillé en tant qu’expert en sécurité dans des organisations qui avaient des fonctions de sécurité cloisonnées, ce qui facilitait leur compromission. Bien que frustrant, cela m'a rétrospectivement permis de constater que cela a vraiment nui à la posture de sécurité de ces organisations. En effet, il n'y avait pas de langage commun, de contexte ou d'objectifs partagés entre les développeurs, les opérations et les responsables de la sécurité. Cela se traduisait par une tension constante et un ralentissement de la publication des logiciels et de leur niveau de sécurité.

Plus tard, devenu leader d’équipes construisant des produits de sécurité, j’ai réalisé que nos entreprises clientes se battaient pour établir des liens entre les équipes produit et l’entité chargée de la sécurité. Il m'apparaît clairement que non seulement ces silos étaient profondément ancrés dans la culture, mais qu'ils étaient renforcés et exacerbés par l’utilisation d’outils différents, de données non partagées, et des motivations différentes. Cette déconnexion crée des équipes dont les objectifs, le langage et le contexte ne sont pas alignés. Par conséquent, créer des workflows de sécurité efficaces et collaboratifs devient presque impossible. On retrouve ce problème dans de nombreux cas, qu’il s’agisse de  workflows pour la mise en œuvre et le passage à l'échelle de l'infrastructure, la création d'une stratégie d'observabilité et le déploiement d'outils de monitoring, ou bien encore la réponse aux incidents.

À l'instar du DevOps, qui a évolué pour faire tomber les barrières entre les mondes spécialisés des développeurs et des opérations, le DevSecOps est plus qu'un simple ensemble d'outils et de processus. Il représente un changement fondamental de culture : faire de la sécurité un élément fondamental de tous les workflows. L’unification des workstreams est profitable aux organisations à plusieurs égards. Elle accélère la communication entre les équipes d'ingénierie et de sécurité, ce qui leur permet de résoudre plus rapidement les problèmes de sécurité. Elle confère la responsabilité aux ingénieurs de la sécurité de leurs applications, les poussant à prendre en compte la  sécurité lors du design de leurs fonctionnalités, et de collaborer avec les équipes de sécurité pour évaluer les risques et réfléchir aux solutions. Enfin, les workstreams unifiés donnent aux équipes de sécurité le contexte et la compréhension dont elles ont besoin pour mener des enquêtes et des examens de sécurité de meilleure qualité, et pour partager facilement leurs conclusions avec d'autres. L’ensemble de ces avantages se traduit par des applications et des infrastructures plus résilientes. Lorsque des problèmes de sécurité sont découverts et résolus en amont, de préférence avant qu'ils n'atteignent la production, ils sont aussi moins coûteux à résoudre. 

DevSecOps en pratique

Lorsqu’il s’agit de faire de la sécurité une partie intégrante du DevOps, il est souvent difficile de savoir à quoi cela ressemble. En pratique, la sécurité peut tirer parti d'outils déjà utilisés, tels que l'automatisation, qui joue déjà un rôle important dans la réussite de DevOps. Par exemple, la collaboration entre la sécurité et l'ingénierie permet de définir un ensemble commun de règles et de les appliquer de manière appropriée dans un pipeline CI/CD, minimisant ainsi les frictions. Cela empêche les vulnérabilités d’être déployées en production, où elles seraient plus coûteuses à résoudre.

L'intégration de la sécurité au DevOps s'applique également au monitoring. Tout système qui crée un contexte partagé par le biais d'une vue unifiée des données de télémétrie dans plusieurs équipes fournit non seulement une meilleure visibilité sur l'état des applications et de l'infrastructure, mais aussi sur la posture de sécurité. Il facilite également le changement culturel nécessaire à l'adoption réussie du DevSecOps.

Un exemple concret du DevSecOps est l'intégration d'ingénieurs en sécurité dans les équipes d'ingénierie des plateformes. Lorsque le contexte de monitoring est cohérent, une telle intégration d’équipes augmente les chances de réussite. Cette transition favorise également des programmes tels que les champions de la sécurité, qui peuvent défendre de bonnes pratiques de sécurité au sein d’équipes individuelles