Introduction au DevSecOps
Rappels sur le DevOps
La notion de DevOps, inventée aux alentours de 2007/2008 par Patrick Debois, est un ensemble de pratiques consistant à faire travailler les développeurs (Dev) et l’équipe d’exploitation (Ops pour operations) vers un objectif partagé et en fournissant un effort commun. Le DevOps n’est ni une personne ni une équipe, mais bien un ensemble de pratiques, amenant aussi l’adoption de nouveaux outils, qui encouragent la collaboration entre les deux entités, apportant ainsi une meilleure fluidité dans l’exécution des différentes tâches. Pour aller plus loin, le DevOps peut être qualifié de culture, car il met en avant l’apprentissage, l’amélioration continue, la responsabilisation et l’autonomie des équipes et des personnes. L’objectif est d’unir les forces pour être en mesure de proposer des produits de meilleure qualité et plus rapidement aux clients de l’entreprise. Elle amène avec elle une forte notion d’automatisation et de surveillance (monitoring) sur la totalité des étapes composant la création d’une application jusqu’à son déploiement. Cela ne se termine pas une fois l’application en production. Il est nécessaire de poursuivre une analyse en continu des performances, des incidents (bugs), des retours...
Cycle de vie du développement logiciel
1. Les étapes du développement logiciel
Le cycle de vie du développement logiciel (Software Development Lifecycle, SDLC) est un processus qui correspond aux étapes effectuées pendant le développement d’une application jusqu’à son déploiement. Le suivi de ces différentes étapes permet à l’entreprise d’être plus efficace, de réagir plus tôt en cas de problème et ainsi de gagner du temps, et donc de l’argent.
La gestion du cycle de vie des applications (Application Lifecycle Management, ALM) est un processus qui englobe le SDLC. Là où le SDLC se concentre uniquement sur le processus de développement de l’application, afin de répondre à l’objectif de créer un logiciel robuste, l’ALM, lui, va également intégrer des notions de gestion de projets, de la gestion de fin de vie et de son obsolescence.
Bien qu’il puisse être légèrement différent selon les sources et les besoins, le processus est cyclique et se divise généralement en six étapes :
a. Planification
La phase de planification peut être vue comme une première évaluation de la demande du projet. Elle va permettre de poser les bases du travail à venir. En général, une équipe de quelques personnes va être amenée à récupérer les exigences du client et à en évaluer la faisabilité. Suite à cela, l’équipe va identifier les personnes concernées par le projet, établir un premier calendrier et effectuer une première estimation des coûts. À cela peuvent s’ajouter des aspects...
L’approche CI/CD
L’utilisation d’une chaîne d’intégration continue (Continuous Integration, CI) et de livraison continue (Continuous Delivery, CD) ou de déploiement continu (Continuous Deployment, CD) est un ensemble de pratiques visant à améliorer et à accélérer le rythme de déploiement des applications au sein de l’entreprise. Pour cela, la chaîne d’intégration va s’appuyer sur un ensemble de processus automatisés permettant de gagner en rapidité et en minimisant les possibilités d’erreurs humaines.
Un des objectifs de l’approche DevOps est de réduire le délai entre le début de la conception d’une application et de sa livraison. Pour cela, il est naturel de se tourner vers la mise en place d’une chaîne d’intégration et de déploiement continue.
1. L’intégration continue
L’intégration continue est une méthode permettant de mettre en place un ensemble de pratiques concernant le code de l’application et son développement. Lorsqu’un programmeur termine le développement d’une nouvelle fonctionnalité, son code sera intégré à l’application dans un référentiel centralisé grâce à un logiciel de gestion de versions. Le logiciel de gestion de versions...
L’intégration de la sécurité
1. Le DevSecOps
Le DevSecOps est une évolution du DevOps dont la philosophie a été repensée afin d’intégrer la sécurité dès le début du cycle de vie des applications. Avant cela, la sécurité était généralement la responsabilité d’une équipe sécurité qui intervenait à la fin du cycle de développement du projet. Son objectif était de garantir que l’application ne possédait pas, ou le moins possible, de vulnérabilités. Cette analyse s’effectuait généralement avant la livraison au client ou une fois sa mise en production effectuée. Plusieurs problématiques se dessinaient alors :
-
L’équipe sécurité n’était pas intégrée au projet assez tôt dans la conception de l’application, ce qui implique qu’elle ne connaissait pas, ou peu, l’application avant la phase d’audit, rendant plus difficile la recherche de vulnérabilités.
-
La correction de vulnérabilités entraînait un coût important car les modifications à effectuer par les développeurs ou les exploitants pouvaient parfois être longues et importantes, réduisant l’efficacité des principes DevOps appliqués par l’entreprise.
-
Plus les cycles de développement étaient courts, moins cette méthode fonctionnait car l’équipe sécurité intervenait plus souvent sur une durée très réduite, réduisant la probabilité d’identifier des vulnérabilités. En effet, l’équipe de sécurité va généralement tester seulement les changements qui ont été effectués, mais ne testera pas l’impact qu’ils peuvent avoir sur le reste de l’application.
Maintenant que les développeurs et les exploitants travaillent de concert, il va être possible d’ajouter un troisième acteur, qu’est la sécurité, laissant ainsi place au DevSecOps. Il ne faut pas s’y tromper, le DevSecOps n’est pas l’intégration d’une équipe sécurité...