Pourquoi mettre en place la démarche DevSecOps dans un projet ?

La démarche DevOps regroupe les pratiques de collaboration entre le développement de logiciels et l’administration des infrastructures informatiques. En ajoutant la notion de sécurité, elle devient DevSecOps (Development – Security – Operations), pour souligner l’importance d’intégrer la sécurité des données dès le début du cycle de vie d’un projet.

La démarche DevOps regroupe les pratiques de collaboration entre le développement de logiciels et l’administration des infrastructures informatiques. En ajoutant la notion de sécurité, elle devient DevSecOps (Development – Security – Operations), pour souligner l’importance d’intégrer la sécurité des données dès le début du cycle de vie d’un projet. Assimilée à la culture, les processus et les outils DevOps, cette démarche permet d’éviter les effets tunnels, et s’assurer que la rapidité de développement ne se fait pas au détriment de la sécurité.

Vincent Barthez, responsable du Centre de Compétences Digital Foundation, nous partage ses convictions sur une démarche à la logique évidente, mais qui trouve encore trop peu de mises en pratique sur le terrain.

Peux-tu nous donner ta définition de la démarche DevSecOps et du «shift left» ?

La démarche DevSecOps consiste à intégrer la sécurité dès la phase de conception d’un projet. Quand nous parlons de DevSecOps, cela introduit la notion de shift left, principe emprunté à la méthodologie DevOps , qui consiste à placer les tests le plus tôt possible dans le cycle de vie d’un projet. Le DevSecOps, c’est simplement déplacer en amont les tests de sécurité. Ce qui s’oppose à une démarche plus « traditionnelle » qui consiste à sécuriser les environnements seulement à la fin du processus, et de ce fait risquer de conserver des vulnérabilités à l’intérieur du Système d’Information.

Concrètement, comment mettre en œuvre cette démarche DevSecOps ?

Le fait de déplacer l’ensemble des tests en amont, y compris ceux concernant la sécurité, permet de poser des points de passage de vérification de la sécurité à chacune des phases du cycle d’un projet. Chaque étape passée avec succès indique que le code est « sûr », et rend concrète la prise en charge de la sécurité dès la conception.

Cela commence dès la phase de planification lors de la construction du backlog, avec l’activité de Threat Modeling qui permet d’identifier les menaces potentielles, par rapport à une infrastructure ou une organisation (via un système de scoring), et d’établir un classement par ordre de priorité. Nous pourrions appeler cette première phase le « sprint 0 ». Les équipes de sécurité du client sont réunies lors d’ateliers de sécurité, qui serviront à définir la criticité.

Mais la démarche DevSecOps se prolonge tout au long du projet ?

C’est le principe. Après la phase de planification, dès l’écriture du code, des scans statiques (SAST) peuvent être effectués. Ils sont basés sur des bibliothèques de CVE (Common Vulnerabilities and Exposures) qui référencent et numérotent de manière publique toutes les failles de sécurité connues ainsi que les méthodes d’attaques utilisées. L’analyse SCA (pour Software Composition Analysis) permet également de dresser l’inventaire des bibliothèques Open Source utilisées et les éventuelles failles associées.

C’est dans la phase build que sont réalisés des tests dynamiques de sécurité des applications (DAST). Il s’agit d’une approche de type « boîte noire » sur l’application en cours d’exécution, qui vérifie les vulnérabilités connues telles que les scripts inter-sites, les commandes et l’injection SQL, ou la configuration non sécurisée d’un serveur. Ces scans sont particulièrement adaptés aux infrastructures modernes générées par code ou IaC (Infrastructure as a code) car elles représentent de nouvelles menaces du fait de leur constitution.

Dans les phases suivantes de l’approche DevOps, on retrouve la gestion des identités et des accès (IAM), la gestion des secrets et enfin après le déploiement, les tests d’intrusion, l’analyse de log ainsi que la surveillance traditionnelle.

Ce sont tous ces éléments mis bout à bout qui constitue l’approche DevSecOps, et qui fait en sorte qu’à aucun moment la sécurité n’a été négligée.

L’approche shift left qui vise à déplacer les tests de sécurité en amont ne revient-elle pas également à déplacer les responsabilités ?

Plutôt à les partager. L’approche DevSecOps représente en effet un enjeu de responsabilités sécuritaires, qui n’est plus uniquement à la charge des équipes de sécurité, mais également aux équipes de développement et d’infrastructure, toujours dans le but d’éviter d’introduire des vulnérabilités, comme l’écriture des mots de passe en dur par exemple. Une approche DevSecOps, c’est aussi une acculturation, une nouvelle façon de penser et de se poser les questions, car il n’y a pas de « super consultant DevSecOps », mais un partage de compétences diverses et complémentaires, et donc de responsabilités.

Finalement, en 2022, peut-on encore dissocier DevOps et DevSecOps ?

Aujourd’hui, c’est une hérésie de ne pas penser aux questions de sécurité dans une approche DevOps. Pourtant, beaucoup de clients ne se demandent pas lors des phases de déploiement si leur démarche est sécuritaire, or la sécurité n’est pas une option. Les risques en termes de cybersécurité n’ont jamais été aussi grands, et les infrastructures modernes sont également beaucoup plus vulnérables et susceptibles de contribuer à la propagation de code malveillant ou autre attaque. La conteneurisation en est une illustration parfaite, car la flexibilité qu’elle apporte dans la conception d’infrastructures ou d’application ne doit pas occulter les risques qu’elle induit. Cela est particulièrement vrai dans les architectures dites de micro-services dans lesquelles la communication est la base de la performance, et la multiplication des images basées sur des bibliothèques peut engendrer de plus en plus de failles de sécurité.

La démarche DevSecOps ne propose donc que des avantages ?

En repositionnant la sécurité au centre de la démarche DevOps, qui consiste à faire collaborer des personnes possédant diverses expertises (Dev, PO, scrum, métiers…) les chances de réussite d’un projet augmentent sensiblement.

En partahttps://insidegroup.fr/expertises/conseil-et-accompagnement-it/nt du principe que chaque livraison est déjà sécurisée, et qu’il n’est plus nécessaire de prévoir des tests supplémentaires, le gain de temps est important.

L’automatisation des processus de vérification de la sécurité va également limiter les manipulations et donc les erreurs humaines. Cette diminution des erreurs humaines associée à un gain de temps abouti à une amélioration du Time to Market. Le ROI se mesurera alors simplement en comparant l’investissement nécessaire avec les éventuels coûts liés à un arrêt de production ou à la compromission d’un système.

DevSecOps, comment faire le premier pas ?

Il est possible de procéder par étapes successives, en intégrant petit à petit des briques de sécurité dans un projet, quelle que soit sa maturité. Cela peut se faire au niveau du code en réalisant ponctuellement ou de façon récurrente des scans de type SAST ou DAST, ou en intégrant des campagnes de tests d’intrusion à des moments clés du cycle de vie de l’application ou de l’infrastructure. Le retour sur investissement est démontrable rapidement grâce à un niveau de sécurisation qui s’améliore instantanément.

En résumé, il n’est pas nécessaire de tout révolutionner dès le départ pour mettre en œuvre cette démarche, mais plutôt de progresser en mode « quick Win » afin de susciter l’adhésion et gagner en maturité. Plus important, dans un domaine d’expertise extrêmement pointu, il est nécessaire de se faire accompagner pour être sûr de posséder toutes les compétences nécessaires au bon moment !

Aujourd’hui, c’est une hérésie de ne pas penser aux questions de sécurité dans une démarche DevOps.