Faut-il obligatoirement se lancer dans le DevSecOps parce que les projets travaillent en Agile ? Quelques questions doivent être posées afin d’y voir plus clair.
Dans les articles précédents, nous avions beaucoup parlé de la façon dont la sécurité devait s’organiser pour accompagner des projets agiles : le changement de paradigme sécurité pour assurer le Security by design, comment organiser les équipes SSI face à ces changements, les méthodologies possibles pour tout de même continuer à analyser les risques ou les homologations de sécurité (et un rappel global de ce à quoi ressemble la sécurité dans l’agile).
Ces articles évoquaient surtout les changements de paradigme organisationnel et méthodologique que vivaient les équipes SSI, afin de pouvoir accompagner au mieux les projets, qui délivrent du code beaucoup plus rapidement.
Les liens entre Agilité et DevOps
En décalant un peu le regard vers les équipes de développement, et avec des retours d’expérience terrain, il s’agit aujourd’hui de traiter plus en profondeur les solutions logicielles et les processus permettant à la sécurité de venir s’intégrer directement dans les chaines de développement et dans le quotidien des développeurs, là où méthodologies Agile et DevOps, bien qu’elles visent les mêmes objectifs d’apport de valeur aux clients, vont s’exprimer différemment.
Le mouvement DevOps étant plus tardif que les méthodes Agile, les équipes de développement se sont organisées plus tôt que les opérations dans un mode itératif et rapide pour la livraison d’applications et de service. Les principes DevOps viennent pallier cet écart, en rapprochant les équipes Opérations et Développement, et en proposant encore des solutions d’accélération des livraisons, par l’automatisation forte du cycle de vie du développement logiciel, via les pipelines CI/CD. Au final, les deux approches viennent s’alimenter et se compléter, pour livrer plus vite et avec une meilleure qualité, grâce à l’automatisation d’un grand nombre de tâches, évitant ainsi des erreurs humaines.
Et la sécurité ?
Pour revenir à notre marotte, il s’agit désormais d’automatiser la sécurité le plus possible. Au même titre que les méthodes Agile et DevOps, la Sécurité dans l’Agile et le DevSecOps sont également très liés. L’idée est en effet de rapprocher toujours plus la sécurité des équipes de développement, mais aussi de la rendre aussi rapide. Un profil clé des principes de sécurité dans l’agile est tout à fait adapté au DevSecOps : celui du Security Champion. Tel que décrit dans l’article « Comment structurer les équipes SSI pour assurer la prise en compte de la sécurité dans l’Agile à l’échelle ? », c’est l’ambassadeur sécurité au sein des équipes de développement. Il fait partie intégrante de l’équipe produit et est présent à chaque sprint. Son rôle est de s’assurer que la sécurité est bien prise en compte à chaque sprint dans le développement des User Stories (en intégrant des Evil ou Security User Stories déjà écrites, ou en aidant à les rédiger). Le Security Champion peut être issu du monde des développements, et monter en compétence sur les sujets sécurité, avec l’aide de la Guilde Sécurité.
Pour aller un cran plus loin, le Security Champion peut aussi aider son équipe à comprendre les solutions automatisées de sécurité, avec l’aide bien sûr d’un spécialiste de l’équipe SSI, qui l’aidera à monter en compétences sur la sécurité applicative.
Cela étant dit, est-ce parce que Sécurité Agile et DevSecOps sont liés qu’il faut automatiquement se lancer dans un programme de transformation vers le DevSecOps ?
Quelques questions préparatoires pour se lancer dans le DevSecOps.
Dans la droite lignée de tout projet de transformation important, il convient de s’interroger sur les raisons de le faire, s’assurer d’avoir un plan et le bon sponsorship. Le DevSecOps n’échappe pas à la règle, même si les questions à se poser restent spécifiques.
Définition des périmètres et objectifs
Tout d’abord, et avant de se lancer, il faut identifier ses leviers de motivation. Est-ce pour livrer plus vite ? mieux ? de façon plus sécurisée ? Les problématiques rencontrées par les équipes Dev, Sec et Ops seront-elles résolues en rapprochant les compétences ? Ceci afin de de prioriser les efforts et s’assurer de pouvoir « vendre » le projet aux sponsors. Ensuite, le périmètre doit être identifié, en essayant de le délimiter entre périmètre transitoire (à court et moyen termes) et périmètre cible (à long terme). On peut commencer le travail sur un portfolio applicatif, une factory pour tester, puis créer la roadmap pour déployer le modèle au périmètre total.
La maturité actuelle de l’organisation en termes d’outillage et d’automatisation dans le cycle de développement des produits doit être évaluée. Une bonne connaissance des outils utilisés dans les chaines est un prérequis. Si trop de zones d’ombre persistent, il faut au préalable démarrer un inventaire des outils existants et un état des lieux des pratiques et processus en place.
Présence des briques essentielles de la chaine CICD
Avant de pouvoir intégrer la sécurité dans les chaines de développement de façon automatisée, il faut d’abord s’assurer d’avoir une bonne vision de ce à quoi peut ressembler une chaine à l’état de l’art. Il est possible de se lancer dans un programme de DevSecOps sans chaines opérationnelles déjà installées, mais avoir une idée claire de la cible est clé. Voici quelques exemples de solutions :
Figure 1 – les briques essentielles d’une chaine CICD (DevOps)
L’entreprise doit être capable également de quantifier les développements réalisés en interne ou en externe, avec des agences de développements. En effet, une chaine complète sera utile pour des entreprises développant principalement en interne : elle est un outil indispensable pour développer vite, avec les bons outils de sécurité intégrés à la chaine. Dans le cas de développements externes, le principe est différent et la sécurité moins « facile » à contrôler : les agences ne donneront pas forcément accès à leurs chaines ou à leur code source. Elles pourront se contenter de livrer des exécutables ou des images, via des dépôts distants par exemple. Intégrer la sécurité se fait donc par des moyens détournés et plus traditionnels : via des Plans d’Assurance Sécurité (PAS) par exemple, ou alors en obligeant contractuellement les agences à former leurs développeur.euse.s en sécurité applicative, via des solutions logicielles de formation (par exemple CodeWarrior, qui délivre des « ceintures » en fonction des niveaux de formation atteints).
Ensuite, une des idées les plus importantes est que la chaine se construit par étapes. Dans la lignée du « test and learn » cher aux méthodes Agile, une version « pilote » de la chaine peut être déployée pour une équipe produit volontaire pour la tester sur quelques semaines/mois. Le déploiement se fait ensuite progressivement, selon une feuille de route préétablie. Dans la plupart des cas rencontrés, les entreprises mettent d’abord en place une chaine DevOps, avec quelques outils d’analyse de code (le plus souvent orientés qualité), puis, une fois que la chaine est considérée comme fonctionnelle, les outils de sécurité y sont rajoutés.
Cependant, il pourrait être intéressant de considérer les outils de sécurité comme partie intégrante de la chaine CICD. Ils pourraient ainsi y être intégrés au fur et à mesure, selon une feuille de route priorisée, comme proposé ci-après.
Voici quelques exemples d’outils constituant la brique sécurité :
Figure 2 – Exemples de solutions de sécurité à intégrer à la chaine CICD (DevSecOps)
D’après nos retours d’expérience terrain, certains outils sont plus « simples » à mettre en œuvre et donc implémentés en priorité.
Outils SAST (Static Application Security Testing)
Comme évoqué précédemment, ces outils sont presque toujours déjà présents dans la chaine initiale, dans leur format de test de la qualité du code. Il s’agit ici de les configurer pour aller un cran plus loin et faire de l’analyse sécurité du code statique. Ce type d’outil peut être intégré à plusieurs endroits de la chaine, dans une logique de « shift-left », c’est-à-dire d’intégration de la sécurité au plus tôt dans la chaine. Il peut être positionné directement sur les IDE (integrated development environment) des développeurs, afin de leur faire des retours « en temps réels » sur les erreurs pouvant introduire des vulnérabilités. Il peut également être utilisé au moment de la compilation du code.
Un inconvénient de ce type d’outils est le nombre assez élevé de faux positifs en résultat. La configuration est évolutive et s’améliore avec le temps. Cependant, la gouvernance et les processus autour de l’outil doivent être pensé en amont : une équipe de triage des vulnérabilités peut être une solution ; la formation des Security Champions à repérer les faux positifs également, avec l’aide d’expert en sécurité applicative (un Application Security Engineer par exemple).
Outils SCA (Software Composition Analysis)
Ces outils devraient logiquement être installés en priorité, les développeurs faisant une grande consommation de bibliothèques open source pour développer leurs produits. Le SCA va vérifier les composants de la bibliothèque, tels que les licences, les dépendances, les vulnérabilités et potentiels exploits. Plusieurs attaques trouvent en effet leur origine dans une utilisation non contrôlée des librairies open source pouvant contenir des vulnérabilités critiques (comme le Log4Shell exploit).
Cet outil peut être utilisé comme le SAST, sur les IDE ou avant la compilation du code.
Outils DAST
Les outils DAST analysent les builds applicatifs en cours d’exécution à la recherche de vulnérabilités de sécurité. Ils permettent la simulation du comportement d’un attaquant malveillant à travers des pentests automatisés et détectent des vulnérabilités de sécurité usuelles telles que les OWASP 10. Ces outils peuvent être moins facile d’utilisation en mode authentifié (l’authentification est difficile en mode automatique, elle doit être effectuée manuellement avant de lancer un test). Les tests prennent aussi plus de temps qu’un scan statique, et des plages doivent être dédiées pour ne pas perturber le travail des développeurs ou la production.
Ils peuvent être utilisés au moment des tests, mais aussi en production.
Il faut penser très tôt à la gouvernance et aux processus à mettre en place autour de ces outils, en s’assurant notamment que les développeurs ne puissent pas passer outre les vulnérabilités détectées (en les passant en « faux positif » par exemple) et d’assurer une centralisation des vulnérabilités dans un outils unique (outil de vulnerability management par exemple), pour plus d’efficacité.
Vérification de la présence des prérequis techniques facilitateurs
L’intérêt de travailler en DevSecOps peut être limité sur des applications de type progiciels non configurables et non instanciables.
Côté infrastructure, l’Infrastructure as Code (gestion et provisionning de l’infrastructure via le code plutôt que via des processus manuels), l’utilisation de containers ou de VM provisionnées permet d’utiliser les chaines CICD de façon plus efficace.
Sans oublier toute la couche de gouvernance et de conduite du changement autour du projet
Il faut s’assurer de construire, ou d’avoir déjà, un modèle opérationnel répondant aux besoins (security champions, enabler teams, outillage, processus). Travailler en mode « agile à l’échelle » n’est pas obligatoire sur les premières itérations (en fonction du périmètre choisi).
Utiliser une méthode de « test and learn » cadrée pour expérimenter est un bon moyen d’impliquer les équipes très tôt, et d’avoir des retours terrains complets et pertinents, avant de commencer le déploiement à l’échelle. Des expérimentations de cybersécurité ont été menées chez des clients, pour savoir quels types de pratiques ou d’outils mettre en œuvre. Quelques exemples :
- Purple teaming, permettant aux développeurs de voir les résultats des outils de tests d’une autre équipe et de tenter de les exploiter (permettant aux développeurs de se rendre compte de la réalité d’une attaque et de la potentielle facilité à la mener à bien),
- Mise en œuvre de solutions comme Cloudbees, pour l’automatisation des processus de la chaine CICD,
- Formation de Security Champions à l’interprétation des résultats des outils de sécurité.
Ces expérimentations font également office de conduite du changement, puisque la plupart des parties prenantes peuvent être impliquées très tôt dans le programme de transformation.
En conclusion
Les chaines CICD sont une véritable opportunité pour la sécurité de s’automatiser. En intégrant les bons outils dans la chaine, les développeurs sont encadrés dans leur pratique, lancé sur des véritables « guardrails » de sécurité, facilitant la production d’un produit sécurisé.
Au-delà de sécuriser les produits, il s’agit aussi de sécuriser la chaine elle-même, au même titre que tout composant ayant de larges accès sur le système d’information : il s’agit de contrôler les accès sur les différents outils qui la composent, s’assurer de la bonne gestion des secrets, du durcissement des serveurs sous-jacents, etc.
Dans un prochain article, nous détaillerons nos convictions sur les piliers du DevSecOps, ou comment réussir une transformation durable et efficace (à base de shift-left, de guardrails et de responsabilisation des équipes sur la sécurité !).
Des commentaires, des corrections ? N’hésitez pas à nous contacter !
