Cependant, il est complexe de mettre en place une chaine CI/CD pertinente et ou on-premise qui demandent également un investissement des équipes d’infrastructure. Les solutions Cloud (PaaS) apparaissent alors comme un bon intermédiaire entre customisation de la chaine CI/CD et simplicité de mise en place. Les solutions cloud permettent également de provisionner des ressources sur demande de façon à s’adapter au mieux aux besoins métier.

Il existe un grand nombre de solutions CI/CD dans le cloud permettant potentiellement de satisfaire les besoins à la fois de sécurité et d’efficacité d’une chaine de développement. Nous proposons ici de présenter notre vision des solutions d’Amazon Web Services (AWS) qui reste un des leader du marché.

Qu’est-ce que les services CI/CD AWS peuvent offrir en termes de fonctionnalités ? Quelle est leur valeur ajoutée ?

Si vous ne connaissez pas AWS CodeCommit, CodePipeline, CodeBuild ou CodeDeploy, nous proposons une entrée en matière pour mieux comprendre le fonctionnement de l’environnement DevSecOps AWS. Afin de présenter un aperçu des outils proposé par AWS, nous décrivons dans les paragraphes suivants le fonctionnement des différents services.

Reprenons depuis le début : du DevOps au DevSecOps

Le DevOps constitue un élément clé du cycle de vie du développement logiciel des entreprises. Le DevOps s’appuie sur un outillage de type CI/CD. C’est une chaîne sur laquelle repose l’évolution du code source en une application livrée en production. La CI/CD accélère les phases de construction, de test et de déploiement afin d’augmenter la fréquence de livraison des applications. Cette accélération est notamment rendue possible par l’automatisation d’un grand nombre de tâches au sein d’un « pipeline CI/CD », comprenez une succession d’actions menant au déploiement en production.

Le DevSecOps rajoute les aspects sécurité au DevOps et s’appuie sur certains outils internes à la CI/CD. Ces outils s’intègrent à tout niveau de la chaîne CI/CD afin de scanner le code source (SAST), les dépendances (SCA) etc. L’objectif est d’intégrer la sécurité au plus tôt, comme présenté dans notre article précédent.

La chaine CI/CD se positionne comme un composant d’intérêt majeur afin d’assurer la sécurité des développements. On peut aller jusqu’à dire que la chaîne CI/CD joue un rôle aussi important dans le développement sécurisé que celui qu’occupe l’AD dans la gestion des identités et des accès (IAM).

La CI/CD dans AWS

AWS offre une multitude de services permettant, en plus des services d’infrastructure classiques, de mettre en place des chaînes de développement continue (du code source à son déploiement) tout en assurant la bonne réalisation des tests de sécurité.

L’orchestrateur CodePipeline permet d’organiser et de lier les différentes étapes de la CI/CD. C’est cet outil qui coordonne la progression au sein du pipeline CI/CD en fonction des résultats des autres outils et services. Si un des outils renvoi un code d’échec, le pipeline peut être bloqué si nécessaire. Les raisons d’un échec du pipeline peuvent être nombreuses : score de sécurité du code insuffisant, échec du déploiement d’un outil…

La gestion du code : SCM et AWS CodeCommit

Les gestionnaires de versions de code (ou SCM : Source Code Manager) sont des outils indispensables dans le développement et sont le point de départ des chaînes d’intégration continue. Ces outils sont essentiels afin d’éditer du code de manière collaborative.

A date, seuls 3 SCM disposent d’une intégration native : GitHub, BitBucket et leur solution propriétaire AWS CodeCommit. Pour toute autre intégration avec un SCM non supporté nativement, il est possible de créer une routine à base de fonctions serverless Lambda et de webhook (notification HTTP) de façon à télécharger le code source dans AWS S3 à chaque commit d’un développeur.

AWS CodeCommit est le service SCM proposé par AWS. C’est un service d’hébergement de code permettant le contrôle de versions et la collaboration supportant les commandes Git, au même titre que GitHub ou GitLab. Ce service a l’avantage d’être pleinement intégré à l’environnement AWS ce qui facilite l’interconnexion avec les autres services AWS. L’utilisation d’AWS CodeCommit permet aussi d’utiliser la solution AWS IAM de gestion des identités et des accès ce qui évite la duplication d’un référentiel d’identité et la gestion des rôles au sein d’un SCM tiers.

Néanmoins, AWS CodeCommit offre des fonctionnalités relativement limitées par rapport à GitHub (ex : UI et expérience utilisateur) et dispose d’une communauté bien plus faible que GitHub ou GitLab.

Tout ceci fait d’AWS CodeCommit une solution convenable dans le cas d’une utilisation au sein d’un environnement entièrement AWS en raison de son intégration étroite à d’autres services AWS tel que AWS CodeBuild ou CodePipeline. En revanche, lorsque la chaîne CI/CD comprend plusieurs solutions externes à AWS, une autre solution telle que GitHub ou GitLab offrira plus de flexibilité.

La phase de build : AWS CodeBuild

Une fois le développement terminé, AWS CodeBuild prend le relais. Cet outil permet aussi bien de compiler/construire une application qu’exécuter des tests via des runners CI. Le service exécute  les instructions qui lui sont passées en entrée dans un fichier buildspec.yml. C’est un outil polyvalent et similaire à un outil CI classique tel que GitLab CI ou GitHub Actions.

AWS CodeBuild permet également d’exécuter les tests de sécurité (SAST, SCA…) en installant et utilisant des applications sur ses runners. Prenons l’exemple de SonarQube, un outil de qualité de code avec un module SAST permettant de scanner du code source pour en ressortir les vulnérabilités. L’exécution fonctionne de la façon suivante :

1. Lorsque le code source est modifié, une notification webhook (requête HTTP POST du SCM) est transmise à AWS (en pratique, cet évènement est géré par AWS EventBridge ou AWS CodePipeline) qui déclenche le test.
2. Le code source est dupliqué sur le runner CI qui effectue un scan de celui-ci et produit un rapport.
3. Ce rapport est ensuite envoyé à un serveur SonarQube (on-premise ou sur une EC2).
4. Après analyse SonarQube produit un rapport final indiquant le niveau de sécurité du code.
5. Ces résultats sont envoyés à CodeBuild qui interprète, selon les conditions présentes dans le fichier yml, si le test est réussi ou non.

Encore une fois, l’intérêt de CodeBuild réside essentiellement dans son intégration à l’environnement et permet une collaboration étroite avec les autres services AWS. Il sera par exemple plus aisé d’attribuer des rôles particuliers aux projets CodeBuild, d’utiliser AWS Secrets Manager (pour la gestion des secrets) ou de permettre le déploiement avec AWS CodeDeploy.

Le déploiement : AWS CodeDeploy

Le déploiement d’une application constitue la fin de son cycle de développement. Au sein d’AWS, le déploiement s’effectue via AWS CodeDeploy. Son rôle est de récupérer les et fichiers de configuration nécessaires dans les buckets S3 dédiés pour ensuite les déployer sur le serveur choisi (EC2…). Il diffère d’AWS Elastic Beanstalk qui permet de déployer une application uniquement grâce à son code (ne supporte généralement pas les langages compilés tel que le C/C++).

Le fonctionnement de CodeDeploy permet de déployer du code sur n’importe quel type de serveur, qu’il soit hébergé par AWS ou non. Son fonctionnement est simple : il suffit d’installer un agent (CodeDeploy agent) sur le serveur cible. C’est cet agent qui est chargé de télécharger les artéfacts, de les installer et de lancer l’application.

Il est nécessaire de définir en amont les instances concernées par le déploiement et leur appliquer un tag AWS arbitraire permettant de les identifier. L’ensemble de ces instances constitue alors un « groupe de déploiement ». Lorsque le déploiement est déclenché, CodeDeploy sélectionne les instances concernées et publie ses instructions. La communication est néanmoins initiée par l’instance cible, c’est bien l’agent CodeDeploy qui contacte (toutes les secondes par défaut) le service CodeDeploy en scrutant pour de nouvelles instructions (polling mode). Ce mode de communication évite toute ouverture de port amenuisant la posture sécurité de l’instance.

AWS CodeDeploy est un outil efficace qui permet le déploiement sur n’importe quel type d’infrastructure. Néanmoins, il nécessite l’installation d’un agent managé par AWS sur l’instance où est déployée le code, ce qui n’est pas toujours souhaitable en fonction du contexte client. On peut imaginer que le polling des instances EC2 peut impacter les performances d’une application critique ou être détecté comme malveillant par un EDR ou NDR (Network Detection & Response).

Sécurisation de la CI/CD AWS

Au vu du rôle essentiel de la chaîne CI/CD dans le développement d’applications, il est essentiel de sécuriser cette infrastructure (sécurisation de l’outillage, intégration, configuration de la chaine…). Ci-dessous nous récapitulons quelques axes d’études à ne pas négliger lors de la mise en place d’une chaine CI/CD AWS. Ces grands principes peuvent être maitrisés via la création de politiques AWS de façon à alerter ou à imposer leur application.

Gestion des flux

Par défaut, les flux vers les services managés AWS (CodeBuild, CodeDeploy…) transitent sur internet avant de revenir vers l’instance cliente de la ressource. Afin d’éviter de faire transiter l’ensemble des flux vers les services AWS par internet, nous recommandons de mettre en place des interfaces VPC endpoints. Ces points d’accès réseaux permettent aux instances au sein d’un VPC de contacter les services AWS comme s’ils étaient déployés au sein du VPC.

Gestion des secrets

Les secrets permettant d’accéder aux services ou à d’autres APIs ne peuvent être stockés en clair dans les SCM ou dans les fichiers de configuration de la chaine. On souhaite éviter toute fuite d’information confidentielle lors d’un accès – légitime ou non – à ces répertoires.

Nous recommandons la mise en place d’un coffre-fort AWS Secret Manager chargé de stocker les secrets (ex : clés API SonarQube…) et de les distribuer aux services uniquement lorsque nécessaire. La récupération d’un secret se fait alors par un appel API à ce coffre-fort avec vérification des privilèges.

Supervision / monitoring

Tout comme n’importe quelle infrastructure, la chaine CI/CD nécessite d’être supervisée. Les solutions AWS natives pour la supervision de services sont AWS CloudWatch pour le recueil de logs, AWS EventBridge pour la création d’alertes et AWS SNS / SQS permettent l’envoie de notification à des groupes prédéfinis (mail, SMS, push notification…). La supervision de la chaine CI/CD permettrait d’alerter des mises en production dangereuses par exemple dans le cas où un projet souhaiterai contourner les politiques de sécurité mises en œuvre.

Identity and Access Management

La gestion des privilèges au sein d’AWS est traité selon le modèle Rôle Based Access Control (RBAC). Chaque action utilisateur requiert une permission spécifique. Par exemple, si un utilisateur souhaite accéder à un bucket S3, il doit d’abord obtenir la permission en lecture associée à la ressource correspondante au S3. On rappellera l’importance du principe du moindre privilège qui consiste à attribuer aux clients (utilisateurs & services) uniquement les droits dont ils ont besoin.

Les droits AWS permettent une configuration totale des accès de chaque client à chaque service / ressource. Cette flexibilité permet de définir précisément le périmètre d’autorisation de chaque acteur de l’environnement AWS. Néanmoins, la finesse des droits peut être fastidieuse à configurer dans une infrastructure CI/CD de grande ampleur.

AWS propose des rôles prédéterminés qui permettent d’appliquer rapidement un ensemble de permissions. Néanmoins, ces rôles prédéfinis ne permettent souvent pas de respecter le principe du moindre privilège. Il est donc important de créer des rôles permettant d’appliquer le principe du moindre privilège sans rentrer dans une micro-gestion des droits.

Nos convictions sur la CI/CD AWS

Les solutions CI/CD présentes dans le Cloud AWS sont intéressantes et nativement intégrées avec les autres services AWS. L’intégration native est particulièrement appréciable notamment dans le cas d’un pipeline entièrement hébergé par AWS. L’appartenance de l’ensemble des outils au même environnement Cloud permet une grande flexibilité, une supervision ainsi que la gestion des droits et identités de manière centralisée. Cependant, le nombre d’options de configurations engendre aussi de la complexité rendant sa maintenance potentiellement fastidieuse au sein d’infrastructures conséquentes.

AWS est un bon choix lorsqu’une entreprise a déjà migré la majeure partie de ses infrastructures chez AWS. Il est possible de tirer avantage des interconnexions entre services et notamment des puissantes solutions de gestion des accès et de monitoring avec peu de configuration additionnelle. En revanche, dans le cadre d’une utilisation simple et isolée, on ne privilégiera pas AWS CodeCommit ou AWS CodeBuild. Des solutions telles que GitHub / GitLab proposent des solutions plus complètes, une meilleure intégration avec d’autres éditeurs et une interface utilisateur plus accessible. Idem côté sécurité, AWS n’offre pas nativement les services de sécurité CI/CD pour attester du code déployé (SAST, DAST…). AWS ne propose pas d’intégration native mais des services tiers peuvent toujours être intégrées relativement simplement.

* « Exemple d’intégration BitBucket dans AWS CodeBuild » – Source 

Cet article CI/CD dans AWS : la solution à tous vos problèmes ? Ce qu’il faut savoir. est apparu en premier sur RiskInsight.

A l’heure où les utilisateurs ont adopté ce produit en masse, cela pose aujourd’hui plusieurs questions fondamentales de cybersécurité.  

Les entreprises doivent-elles laisser leurs employés – spécifiquement les équipes de développement – continuer à utiliser cet outil sans aucune restriction ? Doivent-elles suspendre son usage le temps que les équipes de sécurité se saisissent de la question ? Ou alors faut-il simplement le bannir ? 

Entre autres, certaines entreprises comme J.P. Morgan ou Verizon ont fait le choix d’en interdire l’usage. La société Apple avait initialement décidé d’autoriser l’outil pour ses employés avant de revenir sur sa décision et l’interdire. Amazon et Microsoft ont simplement demandé à leurs employés de faire attention aux informations partagées avec OpenAI. 

L’approche la plus restrictive qui consiste à bloquer la plateforme permet d’éviter toutes questions de cybersécurité mais posent d’autres interrogations, notamment sur la performance et la productivité des équipes, et plus largement de la compétitivité des entreprises sur des marchés changeant rapidement. 

Aujourd’hui, la question du blocage IT de l’intelligence artificielle reste d’actualité. Nous proposons de donner quelques éléments de réponses à cette question pour une catégorie de population particulièrement concernée par la question : les équipes de développement. 

ChatGPT, collecte d’informations personnelles et RGPD 

Le produit d’OpenAI est libre d’accès et d’utilisation sous condition de créer un compte utilisateur. C’est une tendance connue : si un outil en ligne est gratuit, c’est que la source de revenu n’est pas issue de l’accès à l’outil. Pour le cas particulier de ChatGPT, les informations provenant de l’historique des millions d’utilisateurs permettent d’améliorer la plateforme et la qualité du modèle de langage. ChatGPT est un service en preview : toute données entrée par l’utilisateur est susceptible d’être lue par un humain de façon à améliorer les services. 

Actuellement ChatGPT ne semble pas conforme au RGPD et à la loi informatique et liberté mais aucune décision de justice n’a été rendue. Les conditions générales ne font actuellement pas mention du droit à la limitation du traitement, droit à la portabilité des données ou encore du droit d’opposition. La société OpenAI basée aux Etats-Unis ne fait pas mention du RGPD mais rappelle que ChatGPT est conforme aux « CALIFORNIA PRIVACY RIGHTS ». En revanche, cette régulation ne s’applique que pour les résidents Californiens et ne s’applique donc pas au-delà des Etats-Unis d’Amérique. OpenAI ne propose pas non plus de solution pour permettre aux individus de vérifier si l’éditeur stocke leurs données personnelles, ni d’en réclamer leur suppression. 

Enfin, lorsque nous nous attardons sur les mentions légales de ChatGPT, nous pouvons comprendre que :  

1. OpenAI collecte les adresses IP de l’utilisateur, son type de navigateur Web, ainsi que les données et ses interactions avec le site web. Par exemple, cela inclut le type de contenu généré avec l’IA, les cas d’usages et les fonctions utilisées. 
2. OpenAI collecte aussi des informations sur l’activité de navigation des utilisateurs sur le web. Elle se réserve d’ailleurs le droit de partager ces informations personnelles avec des tiers, mais sans préciser lesquelles.  

Tout ceci étant fait dans le but entre autres d’améliorer les services existants ou de développer de nouvelles fonctionnalités.  

Pour revenir aux populations de développeurs, on observe aujourd’hui que la majorité du code s’écrit de manière collaborative en utilisant des outils Git. Ainsi, il n’est pas rare pour un développeur de devoir comprendre un morceau de code qu’il n’a pas écrit lui-même. Plutôt que de demander au rédacteur en question ce qui peut prendre plusieurs minutes (au mieux), un développeur peut être tenté de se tourner vers ChatGPT afin d’obtenir une réponse de manière instantanée. La réponse peut parfois même être plus détaillée que celle que l’auteur du code pourrait fournir. 

Les attaques classiques sur l’IA restent valables 

Plus de la moitié des entreprises se disent aujourd’hui prêtes et décidées à investir et à s’équiper d’outils fonctionnant grâce à l’intelligence artificielle. Par conséquent, il va être de plus en plus intéressant pour les attaquants d’exploiter ce type de technologie. D’autant que la notion cybersécurité est trop souvent ignorée lorsqu’on parle d’intelligence artificielle. 

L’IA d’OpenAI n’est pas immunisée contre les attaques par empoisonnement. Même si l’IA est entraînée sur une base de connaissance conséquente, il est peu probable que l’ensemble de cette connaissance ait fait l’objet d’une revue manuelle. Si nous revenons au sujet de la génération de code, il est probable que selon certains entrants spécifiques l’IA propose du code contenant une porte dérobée (backdoor). Même si ce cas de figure n’a pas été constaté, il n’est pas possible de prouver que celui-ci ne se produira pas selon un entrant particulier de l’utilisateur. 

Nous pouvons également supposer que l’outil n’a été entrainé qu’à partir de sources web relativement sûres. Le LLM (Large Language Model) sur lequel repose ChatGPT : GPT3 pourrait être susceptible à « l’auto-empoisonnement ». En effet, à mesure que GPT3 est utilisée par des millions d’utilisateurs, il est très probable que du texte généré par GPT3 se retrouve au sein de contenus internet de confiance. L’entraînement de GPT4 pourrait donc théoriquement contenir du texte généré par GPT3. Ainsi, l’IA pourrait réaliser son apprentissage à partir de connaissances qui aurait été générées par des versions antérieures du même modèle LLM. Il sera intéressant de voir comment OpenAI contourne le problème d’empoisonnement à mesure que les évolutions sont apportées au modèle. 

L’empoisonnement est une des techniques permettant d’ajouter des backdoors dans le code généré par l’IA, mais ceci n’est pas l’unique vecteur d’attaque. Il est également possible qu’une compromission des systèmes OpenAI permettant de modifier la configuration de ChatGPT afin de suggérer du code contenant des portes dérobées sous certaines conditions. Un attaquant sournois pourrait aller jusqu’à filtrer sur l’identité du compte utilisateur de ChatGPT (par exemple un compte finissant par @grandclientduCAC40.com) pour décider ou non de générer du code contenant des backdoors et autres vulnérabilités. Il est donc nécessaire de rester vigilant du niveau de sécurité d’OpenAI de façon à éviter toute compromission par rebond. 

Chat GPT et la génération de code 

La génération de code via ChatGPT est une des fonctionnalités qui peuvent faire gagner le plus de temps à un développeur au quotidien. Un développeur peut par exemple demander de rédiger un squelette de code pour une fonction puis compléter / corriger les erreurs de l’IA au besoin. Le risque principal induit par cette pratique est ici l’insertion de code malveillant au sein d’une application. 

Cependant, le risque existait bien avant ChatGPT. Un développeur malveillant pourrait très bien obfusquer son code et insérer une backdoor au sein d’une application de manière volontaire. En revanche l’introduction de l’IA apporte une nouvelle dimension au risque dès lors qu’un utilisateur bien intentionné pourrait introduire une backdoor malgré lui. Ceci est à mettre en perspective de la maturité de l’entreprise vis-à-vis de sa chaine CI/CD. La réalisation de scans SAST, DAST et d’audits divers avant la mise en production permet entre-autres de réduire le risque.  

Nous avons constaté que la génération de code via ChatGPT ne suit pas par défaut les meilleures pratiques de sécurité. L’outil peut générer du code utilisant des fonctions non sécurisées comme scanf en langage C. Nous avons proposé à l’outil la requête suivante : « Est-ce que tu peux écrire une fonction en langage C qui permet de créer une liste de nombres entiers grâce à des inputs d’un utilisateur ? ». 

Code généré par ChatGPT suite à l’entrée utilisateur décrite ci-dessus

En analysant le code généré par ChatGPT on remarque – entre autres – trois vulnérabilités importantes :  

(1) Pour débuter, l’utilisation de la fonction scanf permet à l’utilisateur de rentrer n’importe quelle longueur d’input (int overflow…). Il n’y a pas de validation de l’input de l’utilisateur, ce qui reste aujourd’hui un type de vulnérabilité phare remonté par l’OWASP TOP10.  

(2) Additionnellement, la fonction est sensible au buffer overflow : au-delà du 100ème input, la liste list ne contient plus de place pour stocker des données additionnelles ce qui peut soit terminer l’exécution par une erreur ou alors permettre à un utilisateur malveillant d’écrire des données dans une zone de la mémoire qui ne serait pas autorisée afin de prendre le contrôle de l’exécution du programme.  

(3) Pour finir, ChatGPT alloue de la mémoire à la liste via la fonction malloc mais oublie de libérer la mémoire une fois que la liste n’est plus utilisée ce qui pourrait entrainer des soucis de fuite de mémoire (memory leak). 

Chat GPT ne génère donc pas de code de manière sécurisée par défaut contrairement à un développeur expérimenté. L’outil propose du code contenant des vulnérabilités critiques. Si l’utilisateur se révèle assez sensibilisé à la cybersécurité, il est possible de demander à ChatGPT d’identifier les vulnérabilités contenues dans son propre code :  

ChatGPT est capable de détecter les vulnérabilités sur le code ayant été généré par ses soins.

Pour résumer, la génération de code via ChatGPT n’introduit pas de nouveaux risques mais accentue la probabilité qu’une vulnérabilité se retrouve en production. Les recommandations peuvent varier en fonction de la maturité et de la confiance qu’a l’entreprise dans la sécurisation du code livré en production. Une chaine CI/CD et des processus robustes avec des scans de sécurité automatiques (SAST, DAST, FOSS…) a de grande chance de détecter les vulnérabilités les plus critiques.  

Ainsi, ChatGPT n’est pas la seule ressource accessible en ligne par les utilisateurs pouvant permettre l’exfiltration de données (Google Drive, WeTransfer…). Le risque de fuite de données plane déjà sur toute organisation n’ayant pas implémenté une allow-list sur le proxy internet de ses utilisateurs. Le facteur différenciant dans le cas de ChatGPT est que l’utilisateur ne se rend pas nécessairement compte du caractère public des données postées sur la plateforme. Les bénéfices et le gain de temps apportés par l’outil sont bien souvent trop tentant pour l’utilisateur lui faisant oublier les bonnes pratiques. En ce sens ChatGPT n’apporte pas de nouveaux risques mais accentue les probabilités de fuite de données. 

Une organisation dispose donc de deux options afin d’empêcher la fuite de donnée via ChatGPT : (1) former et sensibiliser ses utilisateurs puis leur faire confiance, ou (2) bloquer l’outil.  

Pour les population de développeurs, ici encore la génération de code via ChatGPT n’introduit pas de nouveaux risques mais accentue la probabilité qu’une vulnérabilité se retrouve en production. Il revient à l’entreprise d’évaluer les capacités de sa chaine CI/CD et ses processus de mise en production afin d’évaluer les risques résiduels notamment concernant les faux-négatifs des outils de sécurité intégrés (SAST, DAST…).   

Afin de prendre une décision éclairée, une analyse de risques reste un bon outil pour prendre une décision quant au blocage éventuel de l’accès à ChatGPT. Les aspects suivants doivent être considérés : niveau de sensibilisation des utilisateurs, sensibilité de la donnée manipulée, paradigme de filtrage internet, maturité de la chaine CI/CD… Ces analyses sont bien sûr à mettre en perspective avec les potentiels gains en productivité des équipes. 

Cet article ChatGPT & DevSecOps – Quels sont les nouveaux risques cybersécurité induits par l’utilisation de l’IA par les développeurs ?  est apparu en premier sur RiskInsight.

Comment assurer la sécurité de vos applications malgré l’externalisation de leur développement ?

L’intégration de la sécurité dans les projets est un processus important pour les entreprises pour définir et intégrer les aspects sécurité au plus tôt dans les produits. Cela évite d’augmenter le coût des remédiations si celles-ci n’ont pas été prévues et sont implémentées en fin de projet.

Dans le cadre de développements, l’Agile Security et le DevSecOps définissent les processus et outils à mettre en place pour intégrer la sécurité au plus tôt, comme présenté dans notre article précédent donnant des exemples.

Ces méthodes sont souvent définies sur les développements internes. Cependant, il est fréquent que les entreprises fassent appel à des prestataires externes pour développer une application ou une fonctionnalité particulière. Dans ce cas, il est important de s’assurer que ces prestataires suivent des pratiques de sécurité rigoureuses et qu’ils intègrent la sécurité dans leurs processus de développement aux mêmes standards que le demandeur. Ce qui amène la question suivante :

Développements externes : comment maintenir la confiance dans le code développé de manière externalisée ?

Dans la suite de cet article, nous entendons par code externe l’ensemble des éléments de code qui n’ont pas été développés en passant par une chaîne CI/CD internalisée. Par exemple, un développeur freelance utilisant la chaîne CI / CD interne ou un poste de travail entreprise n’est pas considéré comme un code externe.

Par ailleurs, nous considèrerons deux modèles de livraison d’applicatif en fonction du modèle de développement utilisé par le prestataire :

• la livraison du code source lui-même
• la livraison de l’exécutable, c’est-à-dire le code déjà précompilé

Il est important de noter que ces deux modèles de livraison d’applicatif ont des implications différentes en termes de cybersécurité et de DevSecOps.

Livraison de code

Dans le cas d’une livraison de code, les prestataires externes remettent le code qu’ils ont écrit, généralement sous forme de fichiers sources (par exemple des fichiers .java pour du code Java), à l’entreprise. Cette dernière peut alors auditer, compiler et déployer le code sur ses propres serveurs.

La livraison de code présente plusieurs avantages. Le premier avantage repose sur la flexibilité : en livrant le code source, l’entreprise peut facilement effectuer des modifications et personnalisations sur le code. Elle peut également intégrer le code dans son environnement de développement et de déploiement (CI/CD) existant contenant l’ensemble des outils de sécurité préconfigurés.

L’entreprise n’a alors pas à placer sa confiance dans la sécurité de la chaîne CI du prestataire sur laquelle elle n’a aucun contrôle. De plus, l’entreprise ayant accès au code source peut également l’auditer et ainsi vérifier qu’il est sécurisé. Ces audits tendent à être plus exhaustifs puisque l’auditeur a accès à beaucoup plus de détails sur le fonctionnement du code et peut effectuer à la fois une analyse statique et dynamique du code.

En revanche, la livraison de code présente certains inconvénients. L’entreprise doit disposer de compétences pour adapter les étapes de compilation et déploiement au contexte de production. Si elle ne dispose pas de ces compétences en interne, cela peut entraîner des coûts supplémentaires.x

Voici donc quelques bonnes pratiques afin de maximiser la confiance dans le code livré :

• Partager au plus tôt (contrat, réunion de lancement) les exigences attendues sur la sécurité dans le développement, les versions des logiciels, l’outillage utilisé en interne pour le déploiement, la confidentialité du code source, etc. Certains clients demandent à ce que les développeurs externes aient un certain niveau de certification ou de formation (par exemple, un palier de formation sur Secure Code Warrior, dans un certain langage de programmation).
• Définir et contractualiser les engagements sur les processus de remédiation des vulnérabilités identifiées après livraison du code et le suivi associé (outillage pour le suivi, SLA, etc.)
• Implémenter un contrôle de type hash ou signature sur le code envoyé pour en assurer l’intégrité et définir les modalités de transfert sécurisé du code source avec le prestataire
• Intégrer le code reçu dans la chaîne CI/CD existante y compris les fichiers d’Infrastructure as Code (IaC)
• Réaliser les tests fonctionnels sécurité définis initialement lors du threat modeling : Evil User Stories et Security Stories

Certaines organisations peuvent être confrontées à une situation où la notion de développeurs externes correspond à des développeurs d’autres entités au sein d’un même groupe. Ces entités peuvent avoir leur propres chaînes CI mais dépendre de la chaîne CD ou CI/CD de l’équipe centrale de production.

Dans ces cas, une interconnexion des différentes chaînes CI sur la chaîne CI/CD centrale peut être envisagée. Cette solution permet aux différentes équipes de développer avec les outils leur convenant au mieux.

Le niveau de sécurité assuré par la chaîne CI/CD projet est idéalement équivalent à celui de la production mais ce n’est pas nécessairement le cas. La chaîne CI/CD de production contrôle le code à déployer.

Cependant, le contrôle de la sécurité est souvent effectué trop tard dans le processus de développement. Pour garantir une sécurité efficace dans les développements, il est crucial de s’assurer que la sécurité est intégrée dès le début du cycle de développement (shift-left). Pour remédier à cela, il est recommandé d’offrir des outils de sécurité en libre-service pour les équipes projet afin qu’elles puissent identifier les vulnérabilités dès le début de leur développement en utilisant les outils cibles appropriés.

Dans le cas contraire, les outils de sécurité de la chaîne CI/CD de production permettront d’assurer la conformité aux règles du groupe sans ralentir la mise en production si des contrôles sécurités automatisés ont été mis en place au sein de la chaîne projet.

Cette solution permet aussi à la production de s’assurer de l’utilisation des images (systèmes, docker, etc.) ou des artefacts (bibliothèques) validés par l’entreprise.

Ces interconnexions entre les différentes pipelines peuvent par exemple cloner la branche voulant être déployée par l’équipe produit afin de les pousser en entrée de la chaine CD. Les équipes de production doivent cependant posséder les droits appropriés. Techniquement, le modèle de gestion des droits accordés (idéalement temporairement) doit répondre à la fois au besoin de faciliter l’exécution et au besoin de provision des droits (manuelle vs. automatique), tout en limitant l’accès à l’ensemble des branches ou des projets afin de respecter le principe du moindre privilège.

La majorité des bonnes pratiques citées précédemment s’appliquent aussi afin de réduire le temps de mise en production.

Bien que les méthodes décrites ci-dessus apparaissent comme les plus efficaces pour avoir un contrôle sur des applications développés par des tiers, les entreprises se retrouvent parfois à recevoir des exécutables sans accès au code source. Ceci peut par exemple être le cas pour des raisons de restrictions liées aux licences. Dans ce cas, certaines bonnes pratiques énoncées plus haut ne s’appliquent pas, il est nécessaire de repenser la manière d’intégrer les changements à la production pour ne pas négliger certains aspects sécurité.

Livraison d’exécutable

Dans le cas d’une livraison d’exécutable, les prestataires externes remettent un fichier exécutable (par exemple, un fichier .exe pour des serveurs Windows) qui peut être directement exécuté par l’entreprise sans compilation. Cette méthode de livraison est souvent utilisée pour les logiciels commerciaux qui nécessitent tout de même quelques ajustements de configuration.

Dans ce cadre, l’intégration dans la chaîne de déploiement est beaucoup plus limitée et seules quelques étapes classiques d’une CD peuvent être effectuées sans que les étapes de sécurité de la chaîne CI puissent être vérifiée :

• Réaliser un scan des artefacts
• Réaliser un scan DAST pour détecter les vulnérabilités les plus classiques
• Réaliser des tests d’intrusion

Les rapports des outils de sécurité de la chaîne du prestataire effectuant le développement peuvent aussi être demandés. Ceci doit être inscrit en amont dans le contrat de prestation, avec les exigences sécurité sur le niveau de sécurité du code.

Enfin, une signature du code pour s’assurer de son intégrité est nécessaire lors de l’échange et de l’exécutable. Privilégiez pour cela les signatures via certificats plutôt que les empreintes hash puisque celles-ci permettent de vérifier l’origine (non-répudiation) en plus de l’intégrité de l’exécutable.

Pour conclure, il est important pour les entreprises de s’assurer de la qualité et de la sécurité du code livré par les prestataires externes, surtout lorsque ces derniers développent du code sur des chaînes CI externes. Il existe plusieurs moyens de se convaincre de la sécurité du code livré :

• Des clauses contractuelles claires et précises peuvent aider à définir les attentes et les responsabilités de chacune des parties en ce qui concerne la qualité et la sécurité du code.
• Le partage des spécifications et des attentes en matière de sécurité avec les prestataires externes peut également aider à s’assurer que le code livré répond aux exigences de l’entreprise.
• L’intégration avec les outils de la chaîne de développement interne peut faciliter la vérification de la qualité et de la sécurité du code, ainsi que la mise en place de tests automatisés. Ces intégrations soulèvent des défis à la fois techniques et de processus qu’il faut anticiper pour faciliter le déploiement des développements externes.

En implémentant ces différentes approches, les entreprises peuvent renforcer leur confiance dans le code livré par les prestataires externes et s’assurer de la sécurité de leurs applications.

Cet article Gardez le contrôle de vos développements externes est apparu en premier sur RiskInsight.

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 !

Cet article Sécurité dans l’agilité et DevSecOps : des destins liés ? est apparu en premier sur RiskInsight.

Historiquement l’approche Agile est un ensemble de pratiques utilisées pour des projets de développement informatique.  

Le Manifeste publié en 2001 propose 4 grandes valeurs pour révolutionner la performance des entreprises : 

Ce point d’honneur mis aux interactions humaines entre équipe de développement et acteurs métiers vise à réduire le time to market des produits ainsi développés, par opposition à des projets menés en cycle en V qui une fois livrés, et pour caricaturer, ne correspondaient plus aux attentes du métier qui avaient eu le temps d’évoluer.  

Aujourd’hui cette pratique est appliquée dans la majorité des entreprises à tous les niveaux. Dans le dernier State of Agile Report, sur plus de 4000 entreprises interrogées dans le monde, 95% déclarent utiliser l’agile et 65% d’entre elles le pratiquent depuis au moins 3 ans.  Par ailleurs au-delà des domaines IT, la méthodologie est aussi utilisée dans les directions marketing, ressources humaines, ventes ou encore finances. 52% des entreprises sondées déclarent qu’au moins la moitié des directions de leur entreprise travaillent en agile. C’est un réel passage à l’échelle qu’il ne faut pas louper.  

Au-delà d’une méthode de management de projet c’est une nouvelle philosophie avec des éléments gamifiés. On ne parle plus de réunion mais de cérémonie et de rituel, et de nouveaux rôles apparaissent (product owner et scrum master par exemple). Le souhait est réellement de créer une ambiance de co-construction et d’utiliser au maximum l’intelligence collective pour améliorer les performances de l’entreprise. 

Concernant la sécurité, bien que sous-jacente à la pensée des auteurs du manifeste, ils ne donnent pas plus d’indications que cela pour l’intégrer aux produits. L’intégration de la sécurité dans les projets (ISP) à la mode « cycle en V » n’aurait pas de sens dans un produit Agile ; l’ISP (le « P » pour « produits » cette fois) doit donc se réinventer.  

Quels sont les défis et tendances du domaine ?  

Un de nos défis est d’apporter à nos clients une vision globale de la problématique. Réussir à passer d’une approche traditionnelle à une approche agile nécessite plusieurs niveaux de réflexion pour la sécurité (et d’autres équipes support, telle la qualité, peuvent également être amenées à évoluer en ce sens). Il faut penser organisation certes mais aussi outillage.  

En termes d’organisation, la SSI doit se repositionner comme un service au métier, pour retrouver une image de fonction support, et non plus de « gendarme ». Le rôle de Security Champion est créé : c’est un membre de la feature team (souvent un développeur) qui devient le point de contact privilégié des équipes SSI. Cela permet de recréer du lien avec chaque feature team tout en augmentant l’autonomie sur l’intégration de la sécurité. Cela ne se fait pas en un jour, et un certain nombre de formations doivent être créées et dispensées, pour repartager les enjeux de cybersécurité et de la connaissance (bases de la SSI, développement sécurisé, notamment). Au-delà des formations, cela passe aussi par l’instauration d’une Guilde Sécurité, regroupant experts SSI, Security Champion et toutes personnes intéressées à la sécurité, et permettant d’échanger de l’information sur les dernières actualités sécurité, les bonnes pratiques, mais aussi de partager les retours d’expérience terrain. Cette Guilde doit être outillée pour communiquer le plus simplement possible et pour capitaliser les informations (sur un wiki interne par exemple). 

En tant que référent sécurité, c’est à lui que les développeurs peuvent s’adresser en cas de questions, une fois que l’équipe SSI l’aura formé. Il a donc une casquette assez technique. Les experts SSI gardent leur rôle mais adapté à l’agile ; on va passer d’une relation de contrôle et d’audit à une relation de soutien au fil de l’eau, de facilitateur. Des audits peuvent toujours être réalisés (tests d’intrusion, sur demande de la feature team ou à l’initiative des experts sécurité). De l’outillage méthodologique doit aussi être disponible pour aider les Champions dans leurs tâches et cela passe notamment par la réécriture des risques au format conversationnel. Pour s’adapter à l’utilisation de User Story par les feature teams, l’équipe SSI pourra s’essayer à la rédaction d’Evil User Story, qui correspond à une action réalisée du point de vue d’un attaquant. Par exemple : 

En face de ces risques, des User Story Sécurité, proposant des solutions de remédiation face aux EUS, avec des critères d’acceptance prêts à l’emploi. Tout cela peut être intégré dans une baseline sécurité (également au format backlog, dans un outil de product management, comme JIRA par exemple), proposant un socle minimum de sécurité à intégrer dans les produits. 

Au soutien organisationnel aux équipes doit s’ajouter le soutien technique via l’optimisation de la chaine d’intégration et de déploiement continu (CI/CD) avec des outils visant à automatiser au maximum la sécurité, ce que l’on pourra appeler la Stack Sécurité ou Security pipeline : revue de code, scans de vulnérabilité, détection de secrets, sécurité de l’Infrastructure as Code, etc.).  Une attention particulière doit être porté à sa propre sécurisation, pour ne pas produire l’effet inverse… Dans une optique de shift left security, la sécurité est intégrée par défaut dans le produit, et ce dès le début. Elle adapte donc sa vélocité à celle de l’agile et permet de passer d’une logique de DevOps à celle de DevSecOps.  

Un autre rôle peut être créé, celui d’AppSec Manager. Il fait partie cette fois de l’équipe SSI et est un expert en sécurité logicielle doublé d’un expert de la Stack Sécurité. Il aide les développeurs à prioriser et remédier aux vulnérabilités remontées par la Stack. Il travaille en binôme avec le Risk Manager/Expert SSI, qui lui apporte la connaissance des risques associés au produit, ce qui permet une analyse plus fine des vulnérabilités à traiter en priorité. Tout cela participe à créer une culture de security by design. 

Les défis en mission ensuite sont de s’adapter au maximum aux spécificités client : côté secteur public les attentes et défis sont un peu différents. En effet les ministères sont en train de passer à l’agile mais se pose à eux la problématique des homologations de sécurité de l’ANSSI en neuf étapes. Ce processus s’intègre mal à la méthodologie agile et il faut donc trouver des biais d’adaptation. Une possibilité pourrait être de détailler une checklist de Release permettant à la feature team d’être autonome dans ses mises en production, en sachant quels éléments sont autorisés à passer en production, et lesquels doivent faire l’objet d’une vérification plus approfondie (via un go/no go du RSSI par exemple, ou des contrôles spécifiques).  

Quelles sont les attentes de la part des clients ? 

Les clients RSSI attendent d’être rassurées sur le fait que la sécurité en mode agile ne va pas leur faire « perdre le contrôle » sur la bonne mise en œuvre de la sécurité. Et le modèle que nous proposons responsabilise les feature teams, les outille, mais la sécurité garde le contrôle en centralisant les indicateurs de performance, en ayant la capacité de réaliser des contrôles aléatoires/en fonction de critères prédéfinis, via du bugbounty par exemple ou une enveloppe de jours de pentesters, à répartir sur les différents produits. 

Ensuite, en tant que cabinet de conseil, je pense que les clients attendent de nous le partage de convictions et d’exemples très concrets de ce que nous avons pu réaliser chez d’autres clients. Pour répondre à cette demande, la practice cybersécurité et confiance numérique de Wavestone a créé un certain nombre d’accélérateurs méthodologiques grâce à des retours terrains, prêts à être partagés pour être déconstruits et adaptés. Pouvoir mener nous-aussi la mission en mode Agile fait également partie des attentes, en favorisant la co-construction plutôt que d’apporter des livrables figés et quasi finalisés dès le premier jet. Dans cette optique de gamification chère à l’agile, nous proposons des ateliers de co-construction originaux basés sur l’intelligence collective, grâce à notre asset Creadesk, qui forme les consultantes et consultants et met à disposition des outils de travail collectif à distance. 

Un dernier conseil pour les lecteurs ?  

Mettre en place une véritable démarche en mode test & learn est capital. Co-construire des outils est une chose, mais les tester et les vérifier sur le terrain en est une autre. Anticiper les problèmes est possible jusqu’à un certain point, mais les confronter directement (et les résoudre !) au fur et à mesure représente une valeur ajoutée énorme en mission. Cela permet d’être au contact des métiers et des feature teams directement, de leur montrer que des actions concrètes sont mises en œuvre. La démarche est agile, souple et évolutive. Les accélérateurs, les méthodologies et les outillages proposés évoluent au cours des pilotes et n’en deviennent que plus pertinents pour la deuxième vague de pilotes, jusqu’à ce que toutes les feature teams soient intégrées. 

En parallèle, il faut retenir que la conduite du changement est primordiale. Il faut prévoir un vrai plan de communication, construire les communautés de pratique/les guildes dès les débuts des pilotes, identifier des early adopters qui seront des moteurs précieux du changement au sein même des équipes. L’agile a un impact réel et rapide dans la vie de tous les jours et à tous les niveaux d’équipe : accompagner ce changement est primordial.   

Cet article La sécurité dans l’agile, interview d’Emma Barféty est apparu en premier sur RiskInsight.