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.