Les audits CI/CD réalisés en 2025 et 2026 ont révélé que des identifiants exposés dans des dépôts, des runners mal configurés, des stockages d’artefacts non sécurisés et des rôles cloud trop permissifs constituent autant de vecteurs d’attaque que des acteurs malveillants peuvent exploiter afin d’obtenir un accès persistant et fortement privilégié à l’ensemble de l’infrastructure.

Une vue d’ensemble des outils DevOps est illustrée ci-dessous :

Une compromission à n’importe quelle étape du pipeline peut ouvrir une voie vers des systèmes plus sensibles.

Cet article décrit une chaîne d’attaque CI/CD représentative visant un environnement CI/CD, fondée sur des scénarios observés en conditions réelles. Il met en évidence les vecteurs d’attaque les plus couramment exploités ainsi que les principales mesures de durcissement permettant de réduire la surface d’attaque à chaque étape du pipeline, depuis le code source jusqu’au déploiement en production.

La chaîne d’attaque: de la reconnaissance à la persistance

Reconnaissance et accès initial

La chaîne d’attaque débute généralement par une attaque de phishing ciblant les développeurs afin de voler des identifiants et des codes MFA, bien que le MFA puisse lui-même être contourné via le vol de jetons d’accès ou de détournement de sessions.

Il convient de noter que la compromission d’identifiants seule n’est pas toujours suffisante pour accéder directement à des portails administratifs sensibles. Les contrôles de sécurité autour des interfaces d’administration Microsoft 365 ont été renforcés par des mécanismes de MFA ainsi que, le cas échéant, par des politiques d’accès conditionnel, limitant l’impact du phishing sur les accès hautement privilégiés.

Cependant, dans les environnements d’entreprise modernes où la majorité des applications reposent sur le Single Sign-On (SSO), la compromission d’une session Microsoft (par exemple via le vol de cookies de session) peut donner aux attaquants accès à un large éventail de services interconnectés, incluant les dépôts de code et les plateformes CI/CD. Les attaquants utilisent généralement ce point d’entrée initial pour identifier les environnements de développement et établir une persistance via des mécanismes tels que les Jetons d’accès personnels (PAT).

Un risque souvent négligé survient lorsqu’un compte utilisateur est désactivé au niveau du fournisseur d’identité (ex. Entra ID) mais n’est pas entièrement désactivé dans les plateformes de dépôt. Dans ce cas, des PATs précédemment émis peuvent rester valides, permettant à un attaquant de conserver un accès malgré la révocation du compte.

D’autres vecteurs d’entrée incluent l’exploitation de CVE connues ainsi qu’une mauvaise gestion des identifiants. De nombreuses vulnérabilités majeures sur les outils DevOps sont régulièrement découvertes, ce qui souligne la nécessité d’une gestion continue des vulnérabilités. L’exploitation d’une vulnérabilité critique peut directement fournir un accès privilégié à un outil de la chaîne.

Exemples :

• CVE-2024-23897 (Jenkins), permettant à des attaquants non authentifiés de lire des fichiers arbitraires présents sur le contrôleur Jenkins, exposant ainsi des secrets sensibles,
• CVE-2023-7028 (GitLab), dans laquelle les emails de réinitialisation de mot de passe pouvaient être envoyés vers une adresse électronique non vérifiée.
• CVE-2023-36561 (Azure DevOps Server), une vulnérabilité d’élévation de privilèges permettant à un attaquant d’obtenir un accès non autorisé à certaines fonctionnalités d’Azure DevOps Server, avec un impact potentiel sur les pipelines, les secrets et les ressources des projets.

REMÉDIATION – Renforcer les contrôles d’accès aux dépôts de code source

Afin de réduire les risques liés à l’accès initial, les organisations doivent mettre en œuvre des contrôles permettant d’empêcher les accès non autorisés, de détecter les mécanismes de persistance et de renforcer la gouvernance des identités.

Appliquer des politiques d’accès strictes et réduire l’exposition réseau

• Eviter l’utilisation des comptes génériques ou partagés,
• Utiliser des identités développeurs dédiées, séparées des comptes bureautiques standards (messagerie et outils collaboratifs), afin de réduire l’exposition au phishing et l’impact d’une compromission dans les environnements CI/CD,
• Imposer des mécanismes MFA résistants au phishing (clés FIDO2, certificats, etc),
• Mettre en place des politiques d’accès conditionnel basées sur des critères contextuels (localisation réseau, conformité des appareils).

Mettre en place des mécanismes de détection de persistance

• Surveiller la création ou l’utilisation suspecte de PAT dans GitLab, ainsi que les activités anormales (ex. déploiements à des horaires inhabituels),
• Surveiller l’ajout de nouvelles méthodes d’authentification dans Entra ID, notamment les méthodes sans mot de passe, après un événement de phishing.

Réviser périodiquement les accès et supprimer les comptes inutilisés

• Désactiver ou supprimer les comptes inutilisés ou inactifs,
• Révoquer les accès des collaborateurs sortis de l’organisation sur tous les systèmes,
• Réaliser des revues d’accès périodiques, au minimum tous les six mois pour les utilisateurs à risque élevé.

Compromission des dépôts de code et des pipelines

Les dépôts de code sont souvent directement intégrés aux pipelines CI/CD, ce qui signifie que toute modification du code peut déclencher automatiquement des processus de build et de déploiement. Ainsi, la compromission d’un compte développeur peut influencer la manière dont les applications sont construites et déployées.

Pour réduire le risque de modifications non autorisées en production, les organisations protègent généralement les branches de production (ex. main ou master) via des pull requests, des validations et des contrôles automatisés. En revanche, les branches de développement sont souvent moins strictement contrôlées afin de favoriser la rapidité de développement et de test.

Dans le scénario observé, l’attaquant cible la branche de développement et modifie le fichier de configuration du pipeline (gitlab-ci.yml), en y injectant une commande malveillante (visant à établir un accès distant) au sein d’un job existant. Lors de l’exécution du pipeline, cette commande est exécutée sur le runner CI/CD, ce qui permet à l’attaquant d’obtenir un accès distant à ce dernier.

Une fois dans le runner CI/CD, l’attaquant peut alors exécuter du code arbitraire sur le runner CI/CD et, entre autres, énumérer les variables d’environnement contenant des paramètres de configurations et les secrets définis dans le projet GitLab.

Cependant, il arrive que certains composants de la chaîne CI/CD ne sont pas dupliqués entre environnements pour des raisons de coûts. Dans ce cas précis, les secrets GitLab ne sont pas segmentés entre les environnements de production et de développement. Ainsi l’attaquant est en capacité de lister les secrets de production depuis le runner CI/CD de développement.

Un exemple de variables d’environnement rencontrées dans les pipelines CI/CD est présenté ci-dessous.

Ce flux d’attaque montre comment la manipulation de pipeline permet l’exécution de code dans le runner et l’extraction de variables sensibles de production depuis un environnement de développement.

Parmi les identifiants récupérés dans l’environnement CI/CD compromis, l’attaquant obtient un jeton d’accès à Nexus, système de gestion d’artefacts utilisé pour stocker et distribuer les artefacts de build de confiance consommés par les pipelines situés en aval.

REMÉDIATION – Durcir la sécurité des dépôts de code

La sécurisation du dépôt de code est essentielle pour empêcher l’exploitation des pipelines CI/CD après un accès initial, car les dépôts contrôlent directement le build et le déploiement.

Durcir les dépôts pour limiter les déclenchements de pipeline

• Configurer des branches protégées pour les branches de déploiement,
• Mettre en place des workflows d’approbation multi-niveaux pour les merge requests déclenchant des pipelines et interdire l’auto-approbation,
• Utiliser la propriété du code (ownership) pour assigner et exiger l’approbation des responsables désignés sur les fichiers sensibles (ex. configuration CI/CD).

Limiter la visibilité et les permissions

• Limiter les droits d’écriture aux seuls utilisateurs qui en ont besoin,
• Restreindre la visibilité des projets selon le principe du besoin de savoir (interne ou privé recommandé).

Mettre en place une bonne hygiène de gestion des secrets

• Configurer des secrets CI/CD scopés au niveau projet et privilégier des identifiants éphémères,
• Détecter les secrets en clair le plus tôt possible (au moment du commit ou avant la publication du code) et les révoquer immédiatement en cas d’exposition,
• Réaliser des revues périodiques (ex. audits internes, exercices de red team) sur des plateformes telles que les dépôts Git, Jira ou Confluence afin d’identifier d’éventuelles fuites de secrets passées inaperçues.

REMÉDIATION – Renforcer la sécurité des runners auto-hébergés

Les runners sont des composants critiques des pipelines CI/CD car ils exécutent le code et manipulent des données sensibles. S’ils sont compromis, ils peuvent permettre des mouvements latéraux, l’accès aux secrets ou la prise de contrôle de l’environnement.

Réduire l’exposition réseau et le périmètre d’exécution

• Restreindre le trafic réseau des runners uniquement à ce qui est nécessaire à l’exécution des pipelines, et appliquer des contrôles réseau tels que des proxies et de la segmentation afin d’empêcher tout accès Internet non contrôlé et limiter les mouvements latéraux au sein des réseaux internes,
• Restreindre les déclenchements depuis des dépôts non fiables ou personnels.

Considérer les runners comme des systèmes sensibles

• Considérer les runners comme des serveurs critiques (Application régulière des correctifs du système d’exploitation et durcissement),
• Déployer des solutions de Endpoint Detection and Response (EDR) pour la surveillance des processus, y compris dans les environnements conteneurisés.

Utiliser des runners dédiés et éphémères

• Privilégier des runners dédiés par projet ou environnement. Le partage de runners entre plusieurs contextes augmente le risque de contamination inter-projets et d’escalade de privilèges,
• Utiliser des runners éphémères / autoscalés détruits après chaque job,
• S’assurer que les runners basés sur VM soient également éphémères et isolés afin qu’aucune donnée ou accès résiduel ne persiste entre les exécutions. En complément, s’appuyer uniquement sur des images de base durcies et de confiance (par exemple des golden images pour les runners VM et des images conteneurs approuvées), afin d’éviter toute exécution dans des environnements compromis ou non vérifiés.

Sécuriser les runners containerisés

• N’autoriser que des images approuvées et de confiance dans les exécutions de pipelines afin d’éviter l’introduction de code malveillant via des images compromises ou non vérifiées,
• Appliquer le principe du moindre privilège dans les environnements d’exécution conteneurisés,
• Éviter le mode privilégié et supprimer les capacités Linux inutiles,
• Utiliser des moteurs de build sécurisés (BuildKit / Buildah) lorsque le Docker-in-Docker est requis.

Durcir les runners cloud

• Lors de l’utilisation de runners managés dans le cloud, appliquer une isolation stricte et un périmètre d’identité, restreindre l’accès aux métadonnées afin d’éviter l’exposition d’identifiants depuis l’infrastructure sous-jacente, et s’assurer que les rôles CI/CD sont gouvernés par des politiques IAM strictes en moindre privilège afin d’éviter des permissions excessives.

Empoisonnement d’artefacts et attaques sur les dépendances

Dans les environnements de livraison logicielle, les systèmes de gestion d’artefacts stockent et distribuent les sorties générées par les pipelines CI/CD. Ces sorties, appelées artefacts, représentent les résultats packagés du processus de build, tels que des binaires compilés, des packages applicatifs ou des images de déploiement.

Les artefacts sont stockés de manière centralisée afin d’assurer le versioning, la traçabilité et la réutilisation à travers plusieurs pipelines. En plus des sorties spécifiques aux applications, ces dépôts hébergent souvent également des composants partagés tels que des golden images, des bibliothèques réutilisables ou des dépendances runtime communes. Comme ils proviennent de processus de build considérés comme fiables, les artefacts sont généralement supposés sûrs et largement consommés par les pipelines en aval sans validation supplémentaire.

Dans le scénario observé, l’attaquant utilise des identifiants précédemment obtenus pour s’authentifier au dépôt d’artefacts (Nexus dans cet exemple) avec des permissions excessives (lecture/écriture sur plusieurs catégories, plutôt que limitées à un périmètre applicatif unique), et obtient ainsi un accès à la fois aux artefacts de production et aux artefacts partagés.

Parmi ces derniers, l’attaquant identifie un binaire Terraform légitime utilisé dans le processus de déploiement d’infrastructure (appelé ici le binaire tofu), qui est couramment approuvé et consommé par les pipelines CI/CD pour provisionner et gérer les ressources cloud.

L’attaquant télécharge cet artefact localement et en modifie le contenu en injectant une logique malveillante tout en conservant sa fonctionnalité d’origine, et y intègre un comportement caché conçu pour interagir avec les services AWS Identity and Access Management (IAM) et AWS Security Token Service (STS) afin de récupérer des identifiants.

Le binaire modifié est ensuite téléversé de nouveau dans Nexus, remplaçant la version légitime par un artefact compromis.

À partir de ce moment, tout pipeline CI/CD consommant cet artefact récupère automatiquement le binaire compromis lors de la résolution des dépendances, car il est toujours considéré comme fiable.

Lors de son exécution, le binaire compromis active la charge malveillante intégrée, dont l’objectif est de récupérer le jeton d’accès AWS utilisé par le contexte d’exécution Terraform et de l’envoyer vers un serveur contrôlé par l’attaquant pour exfiltration. Il génère ensuite une sortie obfusquée encodée en Base32. Le décodage permet de reconstruire un objet JSON contenant des identifiants AWS (AccessKeyId, SecretAccessKey et SessionToken).

L’attaquant configure ensuite ces identifiants localement et utilise AWS STS (appel API GetCallerIdentity) pour confirmer l’usurpation d’identité du runner CI/CD.

Cette illustration montre la chaîne d’attaque : compromission d’artefact, injection de logique malveillante, propagation via les pipelines CI/CD et vol final d’identifiants AWS menant à la compromission de l’environnement.

En conséquence, l’attaquant obtient un accès non autorisé aux ressources AWS sous une identité légitime.

REMÉDIATION – Améliorer la gestion des accès à l’Artifactory

Les dépôts d’artefacts tels que Nexus sont des composants clés des pipelines CI/CD utilisés pour stocker et distribuer les dépendances et artefacts de build. Ce sont des cibles à forte valeur pour les attaques de chaîne d’approvisionnement.

La sécurité nécessite des contrôles d’accès forts, une gouvernance des dépendances et une surveillance continue de l’intégrité.

Durcir la plateforme d’artefacts

• Autoriser une large lecture du dépôt uniquement sous deux conditions : depuis le service nécessaire (CI/CD) et si une gestion de mots de passe dans les dépendances existe,
• Restreindre fortement les permissions d’écriture,
• Modifier les identifiants par défaut.

Analyse de composition logicielle (SCA)

• Appliquer une analyse de composition logicielle aux dépendances internes (stockées dans des dépôts locaux) ainsi qu’aux dépendances externes (récupérées depuis des dépôts distants ou proxy) afin de détecter les vulnérabilités connues et les composants obsolètes.

Restreindre les sources d’artefacts

• Maintenir une whitelist de dépôts de confiance afin de garantir que seules des sources approuvées sont utilisées,
• Appliquer des contrôles au niveau des dépôts pour exclure les versions non approuvées ou vulnérables, par exemple dans Nexus ou via des règles d’exclusion dans JFrog Artifactory,
• Empêcher les pipelines CI/CD d’accéder à des sources externes non fiables en imposant des frontières strictes entre dépôts.

Compromission cloud via abus des workloads CI/CD

Dans les environnements cloud, les runners CI/CD sont généralement associés à des rôles IAM privilégiés pour effectuer des opérations de déploiement, incluant la création, modification et suppression de ressources d’infrastructure. Ces rôles incluent souvent des permissions larges telles que AdministratorAccess ou des politiques personnalisées trop permissives, permettant au runner d’interagir avec un large ensemble de services AWS, incluant les services de calcul, le stockage et la gestion des identités.

Lorsqu’un runner CI/CD est compromis, un attaquant peut directement abuser de ces privilèges sans nécessiter d’escalade supplémentaire. Cela peut conduire à un accès immédiat à des ressources sensibles telles que des buckets S3 ou des bases de données RDS, permettant l’exfiltration de données. L’attaquant peut également exploiter les permissions IAM pour assumer d’autres rôles dans d’autres comptes ou projets AWS, facilitant les mouvements latéraux au sein de l’organisation. En outre, l’accès aux services de compute peut être utilisé pour déployer, modifier ou maintenir des charges malveillantes, aboutissant finalement à une compromission complète de l’environnement cloud.

De la compromission initiale du développeur à la prise de contrôle cloud : vue complète de la chaîne CI/CD

la chaîne d’attaque CI/CD commence par la compromission initiale du développeur jusqu’à la prise de contrôle complète de l’environnement cloud.

L’illustration suivante met en évidence les opportunités clés de détection et de surveillance à travers l’écosystème CI/CD. Elle montre comment les données de télémétrie de sécurité peuvent être collectées et corrélées tout au long des différentes étapes de la chaîne d’attaque CI/CD, depuis les activités de développement jusqu’aux runners CI/CD, aux dépôts d’artefacts et aux opérations IAM dans le cloud.

Dans l’ensemble, bien que les pipelines CI/CD élargissent significativement la surface d’attaque, ils offrent également de multiples points d’interception stratégiques où une journalisation centralisée et une surveillance de sécurité peuvent permettre une détection précoce et une réponse aux activités malveillantes.

En conclusion, pour obtenir un pipeline CI/CD sécurisé, la sécurité doit être pensée de bout en bout, des environnements développeurs jusqu’aux systèmes de production.

Les développeurs sont le premier maillon de la chaîne, et la sécurisation de leurs comptes est essentielle. Cela doit être complété par de bonnes pratiques telles que la gestion sécurisée des secrets et la sensibilisation régulière à la sécurité.

Il est également crucial d’assurer une bonne isolation entre environnements et d’appliquer strictement le principe du moindre privilège, aussi bien pour les utilisateurs que pour les comptes de service.

Les problèmes de sécurité ne peuvent pas être corrigés par de simples correctifs si la conception globale du pipeline est faible.

Enfin, les cas d’usage de déploiement doivent être définis clairement dès le départ, car ils influencent directement l’architecture et les choix IAM.

Au-delà des aspects techniques, la sécurité CI/CD doit être évaluée en continu via des audits techniques réguliers ainsi que des revues organisationnelles du cycle de développement afin de maintenir les risques sous contrôle.

Pour une perspective plus large et des recommandations de haut niveau sur le positionnement du CI/CD comme pilier du système d’information, voir l’article RiskInsight : « CI/CD: the new cornerstone of the information system ».

Cet article Sécurité CI/CD : attaque de chaîne d’approvisionnement depuis un développeur compromis est apparu en premier sur RiskInsight.

Les attaques impliquant ces chaînes d’approvisionnement introduisent de nouveaux risques dans les systèmes d’information. Des intrusions peuvent entraîner des fuites de propriété intellectuelle, des altérations de code source, des interruptions de service ainsi que des élévations de privilèges vers des parties plus critiques du SI.  

Quels sont donc ces nouveaux vecteurs d’attaques sur les chaînes CI/CD et comment s’en protéger ? Cet article vise à dresser un panorama de chemins de compromission observés sur le terrain, ainsi que des recommandations pour les contrer. 

Quels risques pour les chaînes CI/CD ? 

L’attaque de SolarWinds en 2020 est un exemple qui ne cesse d’être énoncé, mais qui a mis en lumière l‘ampleur qu’une attaque de ce type peut causer. Après avoir vraisemblablement volé des identifiants FTP laissés en clair dans un ancien dépôt GitHub, l’opération a exploité la chaîne d’approvisionnement de SolarWinds en insérant un beacon C2 (Command & Control) dans leur logiciel de gestion réseau, Orion, en amont du processus de signature. 

Cette backdoor a permis aux attaquants d’accéder aux réseaux internes de plusieurs agences gouvernementales américaines et entreprises privées, et ce, pendant plusieurs mois avant d’être détectée. 

Cet incident, ainsi que des plus récents comme Log4Shell, Codecov et XZ Utils, ont non seulement souligné la nécessité d’une sécurité accrue dans la chaîne CI/CD mais aussi celle d’une réponse à incident beaucoup plus adaptative. L’OWASP présente de façon concrète un panorama des surfaces de risques les plus communes dans leur Top 10 CI/CD Security. 

Fig 1 – Top 10 OWASP CICD-Sec 

Quels retours terrain chez Wavestone ? 

Les audits et tests d’intrusion permettent de détecter des vulnérabilités de façon proactive avant qu’elles ne soient exploitées par des attaquants. En simulant de réelles attaques, ces évaluations offrent une perspective pratique sur la manière dont un système peut être compromis, ce qui permet d’appréhender plus concrètement les potentielles failles dans un système. 

Les différentes interventions menées chez nos clients nous permettent de faire un constat clair : 

• Dans nos audits Cloud et CI/CD, des vulnérabilités sont systématiquement trouvées au niveau des chaînes CI/CD, permettant dans la majorité des cas de prendre le contrôle de la chaîne, des artefacts, voire des infrastructures sous-jacentes.  
• De même, au niveau de nos interventions CERT & RedTeam, nous observons que les chaînes CI/CD sont souvent utilisées comme accélérateur dans les chemins de compromission. 

Regardons ensemble deux exemples d’attaque observés par nos équipes d’audit : 

Ce premier test d’intrusion en boîte grise a permis la compromission totale d’une organisation Cloud AWS (600+ comptes) en partant de comptes standards de DevOps. 

Dans ce scénario d’attaque, 

• Un attaquant pousse du code malveillant vers un repository GitLab, déclenchant une pipeline dans GitLab CI qui déploie ce code dans un pod Kubernetes générique. 
• Ce code ouvre un reverse shell, permettant à l’attaquant de se connecter à distance à l’environnement Kubernetes. 
• Depuis ce pod, l’attaquant exploite le fait que le compte de service associé au nœud dispose de privilèges trop élevés (capacité de patcher des jetons dans le cluster) et patch le jeton du nœud administrateur par un jeton générique. 
• Quand un redéploiement est déclenché, le pod malveillant ne peut qu’être déployer sur l’ancien nœud administrateur bénéficiant toujours des droits admin. 
• Cela permet donc à l’attaquant d’obtenir des privilèges élevés et de se latéraliser dans l’infrastructure AWS, compromettant ainsi le cluster Elastic Kubernetes Service (EKS) et les ressources associées. 

Regardons maintenant un deuxième exemple : 

Fig 3 – Condensé de plusieurs typologies d’attaques observées dans les CI/CD de nos clients 

Ce condensé, présenté à la DefCon & BSides 2022, met en évidence comment différents composants d’une chaîne peuvent être utilisés dans une attaque. Retrouvez cette présentation détaillée sur les nouveaux vecteurs d’attaque liés aux CI/CD en vidéo ! 

Quelles recommandations pour sécuriser sa chaîne CI/CD ? 

La chaîne CI/CD est désormais devenue un composant systémique des systèmes d’information pouvant être utilisée afin de compromettre des ressources critiques d’une entreprise. 

Nos recommandations en matière de sécurité de la chaîne CI/CD peuvent être articulées autour de trois grands axes : la gestion des identités et des accès (IAM), une meilleure conception de la chaîne CI/CD, ainsi que sa surveillance. Ces recommandations suivent notamment le guide DevSecOps de l’ANSSI. 

Fig 4 – Trois grands axes de recommandations pour sécuriser une CI/CD 

Gestion des identités et accès (IAM) 

Fig 5 – Recommandations IAM

Gestion des identités 

Outre les règles traditionnelles de gestion du cycle de vie des identités, il est recommandé d’utiliser systématiquement du Single-Sign On (SSO) avec authentification multifacteur (MFA) afin de réduire significativement le risque d’intrusion en CI/CD. Cela assurerait par exemple que les utilisateurs qui accèdent aux dépôts de code, qui signent un commit ou effectuent tout autre action privilégiée soient légitimés. 

Contrôle des accès 

Il est nécessaire de limiter au maximum les droits des utilisateurs et des comptes de service selon leur fonction dans la chaîne CI/CD, toujours en suivant le principe du moindre privilège. Les comptes sans mot de passe gérés par jetons d’accès doivent également être soumis à une gouvernance claire, avec des règles de cycle de vie, de rotation et de recertification régulière pour réduire les risques liés à leur utilisation. 

Cela peut aussi se faire en passant par du contrôle d’accès basé sur les rôles (RBAC). Par exemple, il ne serait pas utile de manière générale de donner un accès en écriture sur la configuration de la chaîne en elle-même à un développeur travaillant sur un projet spécifique. 

De la même façon, il est pertinent de segmenter ses projets en utilisant différents dépôts de code et de s’assurer que le compte orchestrateur d’un projet n’ait pas des droits excessifs sur le déploiement des projets auxquels il n’est pas rattaché. 

Gestion des secrets 

Les secrets en CI/CD désignent des données sensibles telles que des mots de passe, des clés d’API, des certificats ou des jetons d’accès. Ces secrets permettent notamment d’effectuer des actions privilégiées dans les pipelines et doivent être récupérés de façon automatique. 

Des éditeurs comme HashiCorp proposent des solutions de gestionnaires de secrets pour stocker facilement ses données sensibles et les chiffrer en transit et au repos.  

Conception de la CI/CD 

Fig 6 – Recommandations sur la conception d’une CI/CD 

Segmentation des environnements 

Il est nécessaire de préserver le cloisonnement entre les utilisateurs, les applications et l’infrastructure pour minimiser les impacts en cas de compromission. Reprenant des conseils de l’ANSSI, il faut considérer les actions réalisées par la chaîne CI/CD de production comme des actions d’administration et réduire au maximum le nombre d’utilisateurs pouvant y accéder. De plus, il est nécessaire d’utiliser du chiffrement bout à bout et de s’assurer qu’aucun environnement n’est exposé sur internet. 

Intégration d’outils tiers 

De la même manière que l’attaque SolarWinds, un grand nombre d’attaques de type supply-chain sont à l’origine un composant tiers compromis dans une chaîne CI/CD. Ces outils tiers sont souvent indispensables au bon fonctionnement des chaînes d’approvisionnement, ils peuvent aller d’un simple add-on sur un espace de développement, jusqu’à un outil de contrôle de version ou un orchestrateur. 

Généralement, ces outils se voient accorder des droits leur permettant d’accéder à des ressources sensibles ou d’effectuer des actions spécifiques au sein de la chaîne CI/CD. Si une vulnérabilité sur un outil n’est pas patchée et est exploitée par un attaquant, la capacité d’intervention sera limitée car la résolution de la faille dépendra souvent du fournisseur de l’outil. Il convient donc d’adopter une gouvernance stricte et un processus de Third-Party Cyber Risk Management (TPCRM) pour ces outils tiers. 

Gestion des artefacts 

Pour éviter de stocker des artefacts malveillants, il est recommandé de les signer en amont de la chaîne pour assurer leur intégrité en vérifiant cette signature au moment de leur déploiement. De la même façon, il faut s’assurer de ne pas déployer des librairies malveillantes en réalisant des scans Software Composition Analysis (SCA) régulièrement. 

Surveillance de la chaîne  

Fig 7 – Recommandations de surveillance 

Journalisation et détection 

Garder un haut niveau de visibilité et de contrôle sur tous les composants de la chaîne permet d’assurer une maintenance plus facile et une réponse plus rapide en cas d’attaque.  

Premièrement, il faut mettre en place une stratégie de journalisation adaptée, en maintenant des logs contenant uniquement ce qui est utile à la traçabilité et la responsabilité en cas d’incident. Il faut aussi s’assurer de stocker ces logs de façon sécurisée, ne pas y laisser des secrets en dur, ainsi que les partager efficacement à son Security information and Event management (SIEM). 

Aussi, pour réévaluer sa posture de sécurité et limiter au maximum les possibles chemins de compromission du pipeline CI/CD, des audits et des tests d’intrusion réguliers sont nécessaires.  

Réponse à incident 

Enfin, il faut s’assurer d’inclure sa chaine CI/CD dans ses plans de réponses à incident au même titre que n’importe quel autre périmètre de son système d’information. Il convient par exemple d’avoir des sauvegardes de son code source et ses configurations ainsi que des plans de continuité d’activités en cas de panne d’un outil. 

En conclusion 

Les chaînes CI/CD sont devenues une véritable pierre angulaire dans les systèmes d’information. Ces composants systémiques sont aujourd’hui indispensables pour développer et déployer des applications. Pourtant, leur criticité dans les SI appelle à mettre en place des mesures de sécurité adaptées pour qu’elles ne deviennent pas un vecteur d’attaques.  

Fig 8 – Quelques composants systémiques et critiques en CI/CD 

Outre les recommandations de cet article, d’autres mesures préventives peuvent se traduire plus précisément par des guides de durcissement pour des outils particuliers d’une chaîne. L’adoption d’une stratégie pertinente de formation des utilisateurs ainsi que de conduite du changement est aussi nécessaire pour réussir ces transformations.  

Un grand merci à Jeanne GRENIER pour sa précieuse contribution à la rédaction de cet article.

Cet article CI/CD : la nouvelle pierre angulaire du SI ?  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.