DevSecOps : les bénéfices et les risques de l’automatisation
Lors du sommet virtuel DevOps Live Paris, événement dont LeMagIT était partenaire, nous avons animé un débat consacré à la gestion des risques de sécurité grâce à l’automatisation dans une approche DevSecOps. Cinq intervenants ont partagé leurs points de vue, leurs expériences et leurs conseils quant à cette approche. Dans cet article, nous en tirons les enseignements.
Que ce soit sur site ou dans le cloud, l’on observe une forte croissance du nombre de composants. Il y a bien sûr le fait que les architectures de microservices s’imposent, mais la multiplication des dépendances open source n’est pas étrangère à ce phénomène.
Les entreprises ont bien compris l’intérêt de l’approche DevOps pour faciliter et automatiser la livraison applicative. Seulement, la sécurité des applications et des infrastructures demeure un enjeu majeur que les équipes de développement peinent souvent à maîtriser.
« La multiplication des composants et des équipes rend difficile cette surveillance », constate Christophe Roux Project Manager - Automation Architect chez Devoteam Revolve, lors de la session « Du DevOps au DevSecOps - Mieux gérer les risques grâce à l’automatisation ? » du sommet DevOps Live Paris.
« Dans le cloud, nous sommes sur des ressources mutualisées. Cela veut dire qu’il faut blinder chaque enveloppe », ajoute-t-il.
En plus du possible déficit sécuritaire des briques qui constituent un SI, la chaîne CI/CD représente elle aussi un risque. « En adoptant l’approche DevOps, beaucoup ont oublié la sécurité », affirme François Mermet, Expert DevSecOps chez PMU. « Nous avons mis en place des méthodes synonymes de rapidité, mais nous avons potentiellement ajouté des failles permettant aux pirates de s’insérer dans nos usines logicielles », prévient-il.
« Historiquement, nous avons considéré les chaînes de livraison continue comme des plateformes de développement », rappelle Alain Helaïli, Principal Solutions Engineer chez GitHub. « Aujourd’hui, il faut les considérer comme des plateformes de production. Ce sont des endroits où l’on a vu des attaques très précises : exemple, des packages npm peuvent s’y exécuter automatiquement sans exécuter le runtime. Cela a été utilisé pour remonter des données à des acteurs tiers ».
L’automatisation des démarches de sécurité, une nécessité
C’est dans ce contexte que l’approche DevSecOps prend tout son sens. En principe, elle ajoute cette notion de sécurité dans la boucle de développement et de maintien en opération des applications. Et selon ce mantra, certaines tâches de sécurité peuvent et doivent être automatisées.
« Le DevOps tend à accélérer le développement de nos applications », insiste Yann Crumeyrolle, Leader DevSecOps chez AXA France. « Si l’on n’automatise pas la sécurité au même niveau que le développement et les opérations, l’on est incapable de répondre à ce besoin de sécurité. Chez Axa, nous nous en sommes rendu compte lors de livraisons qui avaient lieu toutes les six à huit semaines. Nous étions en incapacité d’effectuer des pentests au moment de ces livraisons. Si l’on n’a pas de systèmes automatisés qui inspectent les petites évolutions, soit l’on risque de louper des vulnérabilités, soit l’on passe trop de temps à le faire manuellement », constate-t-il.
Lors de cette table ronde, les participants partagent cet avis. « Le rapport entre développeurs et experts de sécurité est largement disproportionné. Il n’est pas possible de mettre un expert de la sécurité derrière chaque développeur », affirme Alain Helaïli.
« Je travaille dans une entreprise en forte croissance. Il faut pouvoir gérer la sécurité des applications sans avoir à multiplier la taille de l’équipe dédiée par trois, cinq, ou dix », ajoute Ayoub Elaassal, Head of Information Security chez Qonto. « L’automatisation permet de le faire. D’un point de vue personnel, je me demande toujours après avoir effectué une tâche si je peux l’automatiser, pour que la prochaine fois elle ne me prenne plus trois semaines, mais deux heures, voire si je peux m’abstraire de la chaîne de création de valeurs ».
Les bots doivent informer avant d’agir
Est-ce à dire qu’il faut automatiser toutes les démarches de sécurité ? Les intervenants sont catégoriques à ce sujet : non.
« Il y a deux grandes raisons pour automatiser », résume Christophe Roux. La première concerne le volume : quand l’on veut déployer de plus en plus souvent un plus grand nombre de systèmes. La deuxième raison, c’est quand une tâche est dite critique ou complexe, lorsque ce processus requiert de ne surtout pas se tromper ou d’oublier des étapes comme des tests de sécurité. Le fait d’avoir inséré ces opérations dans la chaîne, nous sommes sûrs qu’elles seront jouées ». En cas d’automatisation des remédiations, l’automate « doit rendre des comptes, donner des éléments d’explication ».
« J’essaye d’adopter une méthode dite 80/20. Si je peux adresser 80 % des risques avec 20 % d’effort, je prends », avance Ayoub Elaassal. « Il y a un certain nombre d’approches simples pour repérer des vulnérabilités qui sont activement exploitées, l’on peut les automatiser, créer des alertes et les faire remonter sur les outils de supervision ».
« L’on déploie beaucoup d’automates pour faire, et pas assez pour montrer. Le bénéfice tient dans le fait d’informer la personne qui peut agir [...] ».
Christophe RouxProject Manager - Automation Architect, Devoteam Revolve
Selon Christophe Roux, l’on n’automatise pas la prise de décision, mais bien la collecte d’informations : les tests unitaires, les tests d’intrusion, les scans de vulnérabilités, de dépendances et des secrets (éventuellement leur insertion). « L’on déploie beaucoup d’automates pour faire, et pas assez pour montrer », déplore-t-il. « Le bénéfice tient dans le fait d’informer la personne qui peut agir. Si l’on détecte une vulnérabilité au niveau du développement, c’est aux programmeurs que l’on doit réinjecter l’information afin qu’ils puissent corriger. Je parle du développeur, mais en réalité ceci est vrai à tous les niveaux ».
Pour Yann Crumeyrolle, il faut trouver un juste milieu entre les priorités de sécurité et la nécessité de livrer. « Si l’on fait de la sécurité un point bloquant, le développeur pressé par le temps peut outrepasser les étapes nécessaires de vérification, ou réduire le périmètre de l’analyse pour que le commit passe », prévient-il.
Pour le responsable, la solution ne réside pas uniquement dans l’automatisation, mais dans l’acculturation des équipes à la sécurité. « Il faut bien les sensibiliser pour que les membres puissent tirer de la valeur de cette automatisation imposée et apprennent à interpréter les résultats des scans », recommande Yann Crumeyrolle.
Il s’agit là de distinguer le bénéfice opérationnel de l’automatisation, de celui obtenu par le développeur.
Les outils et l’automatisation ne font pas tout
« Il faut que le développeur n’ait d’autre choix que de livrer quelque chose de sécurisé », renchérit Ayoub Elaassal. « Idéalement, la sécurité est transparente dans le processus de livraison, parce que l’on a choisi un standard fiable. Si la vérification arrive en bout de chaîne de livraison, alors il est déjà trop tard ».
Pour mettre en place cette automatisation maîtrisée, il existe un grand nombre d’outils propriétaires ou open source. Encore faut-il que les informations obtenues et les actions effectuées puissent être maîtrisées par les équipes DevSecOps. Il ne faut pas non plus oublier le coût qu’ils peuvent entraîner, rappelle François Mermet. Deux problèmes peuvent poindre rapidement : le volume d’informations à traiter et leur pertinence.
« Avec certains outils, il y a énormément d’informations. Les développeurs sont tellement noyés qu’ils finissent par ne plus consulter les alertes. Il faut de l’information pertinente », martèle François Mermet.
« Personnellement j’ai laissé tomber les outils de scans de conteneurs, parce que c’était bruyant, pas intéressant », indique Ayoub Elaassal. « En revanche, des outils comme Dependabot ou Renovate permettent de limiter cet effet de fatigue avec une suggestion de mise à jour quotidienne ou hebdomadaire, suivant leurs configurations ».
Yann Crumeyrolle recommande de procéder de manière logique, en traitant en priorité les alertes de haut niveau, avant de se pencher sur celles qui concernent des risques modérés et faibles.
Protéger la supply chain logicielle des effets potentiellement nocifs de l’automatisation
« Chez GitHub nous savons étudier les dépendances, réaliser des analyses statiques du code, mais il faut prendre en compte tous les éléments de la chaîne, cela devient complexe », prévient Alain Helaïli. « Nous voyons de plus en plus de problématiques liées à l’Infrastructure as Code, entre autres. Il convient de protéger sa supply chain : c’est là que l’on rencontre les plus grands risques, parce qu’elle est accessible à beaucoup d’utilisateurs ».
Introduire des flux de vérifications et des prises de décision automatisées relatifs à la sécurité n’est pas sans risques.
« Il y a deux types de risques qui peuvent s’introduire à ce niveau-là. Par exemple lors du téléchargement de mise à jour de nouveau package, il y a un risque que ce package soit vérolé. Deuxièmement, si l’on délègue tout à la CI/CD, l’on ouvre la vulnérabilité sur la partie supply chain. Par exemple, si l’on automatise la génération et l’utilisation de mot de passe, il faut éviter que cette étape soit complètement scriptable », déclare Alain Helaïli.
Selon Christophe Roux, les automates sont « critiques ». « Ils manipulent des données sensibles, des mots de passe, des certificats. L’on devrait les administrer telles des applications critiques, comme celles qui manipulent des données bancaires », assure-t-il. « Les processus existent en entreprise, simplement il est parfois difficile de savoir ce que l’on juge critique ou non ».
Éducation à la cybersécurité : la stratégie du « sachet de thé »
Pour s’en prémunir, François Mermet recommande d’éduquer les utilisateurs, développeurs ou ops. « Si les gens se sentent concernés, ils feront plus attention à ce qu’ils font. Les outils existent, mais ils ne font pas de miracles. Ils ne permettent pas de détecter toutes les failles possibles ».
« Ayez une approche basée sur les risques. Listez les scénarios les plus souvent exploités par les attaquants. Ensuite, regroupez-les en catégories, puis déclinez vos démarches opérationnelles ».
Ayoub ElaassalHead of Information Security, Qonto
« Il ne faut pas s’appuyer exclusivement sur l’outillage », confirme Ayoub Elaassal. « Ayez une approche basée sur les risques. Listez les scénarios les plus souvent exploités par les attaquants. Ensuite, regroupez-les en catégories, puis déclinez vos démarches opérationnelles. C’est à ce moment-là que vous pouvez mettre en place les outils nécessaires à votre défense », conseille-t-il.
Yann Crumeyrolle rappelle cette nécessité d’éduquer les membres des équipes DevOps. Tous ne sont pourtant pas sensibles aux risques cyber. Le responsable explique sa méthodologie. « Nous avons mis en œuvre une COP de sécurité, une communauté pour partager les pratiques de sécurité. Les développeurs et les Ops se réunissent régulièrement pour échanger. Suite à ces COP, nous avons pu désigner des référents très appétants, qu’ils soient des Devs ou des Ops. Nous nous appuyons sur ces personnes pour répandre les bonnes pratiques de sécurité auprès des autres. C’est un peu le principe du sachet de thé, vous le déposez dans votre tasse et le tanin se diffuse au fur et à mesure », illustre-t-il.
Et Christophe Roux de rappeler que les risques cyber ne sont pas simplement une menace pour l’usine logicielle ou l’infrastructure administrée par la DSI. « Il ne faut pas perdre de vue que les développeurs, les SRE, les responsables de la cybersécurité sont au service des métiers. L’enjeu est économique », conclut-il. Malheureusement, LeMagIT se fait (trop) régulièrement l’écho de ce phénomène.
