Menaces et attaques CI/CD : ce que les attaquants ciblent et comment se défendre

La livraison logicielle moderne repose sur les pipelines d’intégration et de livraison continues (CI/CD) pour construire, tester et déployer du code à grande échelle. Ces pipelines sont devenus la colonne vertébrale du DevOps, permettant aux organisations de livrer des fonctionnalités plus vite et de manière plus fiable que jamais. Mais cette puissance a une contrepartie critique : les systèmes CI/CD sont devenus l’une des surfaces d’attaque les plus attrayantes des environnements d’entreprise.

Contrairement à l’infrastructure traditionnelle, les pipelines CI/CD se situent à l’intersection du code, des identifiants et des systèmes de production. Un seul pipeline compromis peut donner à un attaquant tout ce dont il a besoin — accès aux dépôts de code source, identifiants cloud, clés de signature et capacité de pousser des artifacts malveillants directement en production. Ce n’est pas une préoccupation théorique. Les cinq dernières années ont vu une escalade spectaculaire des attaques visant les chaînes d’approvisionnement logicielles à travers l’infrastructure CI/CD, de SolarWinds à XZ Utils.

Ce guide propose une taxonomie complète des menaces et attaques CI/CD, les met en correspondance avec des référentiels du secteur comme le OWASP CI/CD Top 10, décrit des incidents réels et présente des stratégies défensives que vous pouvez mettre en œuvre dès aujourd’hui. Que vous soyez ingénieur sécurité, praticien DevOps ou responsable d’une équipe plateforme, comprendre ces vecteurs d’attaque est la première étape vers des pipelines résilients.

Pourquoi les attaquants ciblent les pipelines CI/CD

Pour comprendre le paysage des menaces, vous devez penser aux pipelines CI/CD comme le fait un attaquant. Les pipelines ne sont pas que de l’automatisation — ce sont des environnements d’exécution privilégiés dotés de propriétés uniques qui en font des cibles d’une valeur extraordinaire.

Un accès privilégié à tout

Les pipelines CI/CD détiennent couramment des identifiants pour les fournisseurs cloud (AWS, GCP, Azure), les registres de conteneurs, les dépôts de packages, les bases de données et les clusters Kubernetes de production. Un seul runner de pipeline dispose souvent de plus d’accès que n’importe quel développeur individuel. Les attaquants qui compromettent un pipeline héritent instantanément de tous ces privilèges.

L’automatisation comme arme

Les pipelines sont conçus pour exécuter du code automatiquement en réponse à des déclencheurs — un push sur une branche, une pull request, un tag ou un cron planifié. Cette automatisation, qui est la raison d’être même du CI/CD, devient une arme dès qu’un attaquant peut influencer ce qui est exécuté. Contrairement à un relecteur humain, un pipeline exécutera fidèlement toutes les instructions qu’on lui donne, y compris malveillantes.

Des hypothèses de confiance implicites

La plupart des architectures CI/CD reposent sur un socle de confiance implicite. Les organisations partent du principe que les fichiers de configuration des pipelines n’ont pas été altérés. Elles supposent que les dépendances résolues au moment du build sont légitimes. Elles supposent que les GitHub Actions tierces ou les templates de pipeline partagés sont sûrs. Chacune de ces hypothèses de confiance représente un vecteur d’attaque potentiel.

Une posture de sécurité faible

Les systèmes CI/CD se trouvent souvent dans un angle mort de la sécurité. Ils sont gérés par les équipes d’ingénierie plutôt que par les équipes de sécurité, ils ne bénéficient pas de la surveillance et de la journalisation dont profitent les systèmes de production, et ils accumulent de la dette technique sous forme de configurations trop permissives, d’identifiants périmés et de runners non corrigés. Cela en fait des cibles faciles comparées à une infrastructure de production durcie.

L’amplification par la chaîne d’approvisionnement

L’aspect le plus dangereux des attaques CI/CD est peut-être leur potentiel d’amplification. Compromettre un seul pipeline qui construit une bibliothèque ou un service largement utilisé peut propager du code malveillant à des milliers, voire des millions de consommateurs en aval. C’est cet effet d’amplification par la chaîne d’approvisionnement qui rend des incidents comme SolarWinds et XZ Utils si dévastateurs.

Taxonomie des attaques CI/CD : correspondance avec le OWASP CI/CD Top 10

Le OWASP CI/CD Top 10 fournit un cadre structuré pour comprendre les risques les plus critiques des environnements CI/CD. Chaque catégorie de risque représente une classe de vecteurs d’attaque que les adversaires exploitent activement. Voici comment les principaux types d’attaque correspondent à ce cadre :

Risque OWASP CI/CD	Catégorie d’attaque	Enjeu principal
CICD-SEC-1	Contrôle de flux insuffisant	Approbations manquantes, aucune protection de branche
CICD-SEC-2	Gestion inadéquate des identités et des accès	Comptes de service trop permissifs
CICD-SEC-3	Abus de la chaîne de dépendances	Confusion de dépendances, typosquatting
CICD-SEC-4	Exécution de pipeline empoisonné	Configuration de pipeline malveillante dans les PR/branches
CICD-SEC-5	PBAC insuffisant	Absence de contrôles d’accès basés sur le pipeline
CICD-SEC-6	Hygiène des identifiants insuffisante	Secrets codés en dur, tokens non renouvelés
CICD-SEC-7	Configuration système non sécurisée	Configurations par défaut, serveurs CI non corrigés
CICD-SEC-8	Usage non encadré de services tiers	Actions compromises, intégrations non vérifiées
CICD-SEC-9	Validation inadéquate de l’intégrité des artifacts	Artifacts non signés, mutation de tags
CICD-SEC-10	Journalisation et visibilité insuffisantes	Aucune piste d’audit, angles morts dans la surveillance

Pour une analyse approfondie de chacun de ces risques avec des exemples concrets, consultez notre guide détaillé : Le OWASP Top 10 des risques CI/CD expliqué avec des exemples concrets.

Les sections ci-dessous explorent en détail les catégories d’attaque les plus marquantes, en examinant pour chacune les mécanismes, des exemples concrets et les stratégies de détection.

Exécution de pipeline empoisonné (PPE)

L’exécution de pipeline empoisonné (Poisoned Pipeline Execution, PPE) est l’une des classes d’attaques CI/CD les plus dangereuses et les plus répandues. Elle survient lorsqu’un attaquant manipule la configuration du pipeline CI/CD ou les instructions de build pour exécuter du code malveillant au sein de l’environnement du pipeline. L’attaque exploite le fait que les pipelines exécutent automatiquement les instructions définies dans les fichiers de configuration — fichiers qui peuvent souvent être modifiés par les contributeurs.

PPE direct (D-PPE)

Dans le PPE direct, l’attaquant dispose d’un accès en écriture au dépôt et modifie directement le fichier de configuration du pipeline (par ex., .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, ou azure-pipelines.yml). L’attaquant injecte des étapes malveillantes qui s’exécutent avec l’ensemble des privilèges du pipeline. Cela peut inclure l’exfiltration de secrets, l’injection de portes dérobées dans les artifacts de build ou l’établissement d’une persistance dans l’environnement CI/CD.

Le PPE direct est particulièrement efficace quand :

• les règles de protection de branche sont faibles ou absentes
• les exécutions de pipeline se déclenchent sur des événements push vers n’importe quelle branche
• des runners auto-hébergés à état persistant sont utilisés
• les fichiers CODEOWNERS ne protègent pas la configuration du pipeline

PPE indirect (I-PPE)

Le PPE indirect est plus subtil et plus difficile à détecter. Au lieu de modifier directement la configuration du pipeline, l’attaquant modifie des fichiers que le pipeline consomme pendant l’exécution. Cela inclut :

• Les scripts de build référencés dans le pipeline (par ex., Makefile, build.sh, package.json scripts)
• Les manifestes de dépendances qui importent des packages malveillants pendant le build
• Les fichiers de configuration consommés par les outils de build (par ex., .npmrc, setup.py, build.gradle)
• Les fixtures de test ou fichiers de données traités par les étapes du pipeline

Le I-PPE est particulièrement dangereux car les processus de revue de code se concentrent généralement sur les modifications du code applicatif, et non sur les implications de sécurité des scripts de build ou fichiers de dépendances modifiés. Un attaquant peut dissimuler des instructions malveillantes dans une modification en apparence anodine d’un Makefile qui s’exécute avec l’ensemble des privilèges du pipeline.

PPE via les pull requests

De nombreux systèmes CI/CD sont configurés pour exécuter des pipelines sur les pull requests issues de forks — une fonctionnalité nécessaire pour les projets open source. Mais cela crée un vecteur d’attaque direct : un contributeur externe peut soumettre une pull request qui modifie la configuration du pipeline ou les scripts de build, et le pipeline exécutera le code malveillant avant toute revue humaine. Bien que certaines plateformes restreignent l’accès aux secrets pour les PR de forks, des erreurs de configuration exposent fréquemment les secrets, ou l’environnement du pipeline lui-même offre une valeur suffisante à l’attaquant.

Pour explorer concrètement les techniques d’attaque PPE et apprendre les contre-mesures défensives, suivez notre lab dédié : Lab : exploiter et se défendre contre l’exécution de pipeline empoisonné (PPE).

Confusion de dépendances et empoisonnement d’artifacts

Les attaques par confusion de dépendances et empoisonnement d’artifacts exploitent la confiance que les systèmes de build accordent aux registres de packages et aux mécanismes de résolution de dépendances. Ces attaques visent la chaîne d’approvisionnement à son niveau le plus fondamental — les composants qui sont intégrés à votre logiciel au moment du build.

Confusion de dépendances

La confusion de dépendances (aussi appelée confusion d’espace de noms ou attaque par substitution) exploite la manière dont les gestionnaires de packages résolvent les dépendances lorsque des registres publics et privés sont configurés simultanément. L’attaquant publie un package malveillant sur un registre public (npm, PyPI, RubyGems) sous le même nom qu’un package interne/privé utilisé par l’organisation ciblée. Si le gestionnaire de packages n’est pas configuré pour donner la priorité au registre privé, il peut récupérer la version publique malveillante à la place — surtout si l’attaquant publie un numéro de version plus élevé.

Cette attaque a été démontrée de façon retentissante par le chercheur en sécurité Alex Birsan en 2021, qui a utilisé la confusion de dépendances pour exécuter du code au sein des systèmes de build d’Apple, Microsoft, PayPal et de dizaines d’autres grandes organisations. L’attaque ne nécessitait aucun accès à l’organisation ciblée — seulement la connaissance des noms de packages internes, qui peuvent parfois être découverts via des lock files fuités, des source maps JavaScript ou des messages d’erreur.

Typosquatting

Apparenté à la confusion de dépendances, le typosquatting consiste à publier des packages malveillants dont les noms ressemblent fortement à ceux de packages légitimes populaires (par ex., lodahs au lieu de lodash, reqeusts au lieu de requests). Lorsqu’un développeur ou un script de build fait une faute de frappe dans une déclaration de dépendance, c’est le package malveillant qui est installé à la place.

Empoisonnement d’artifacts

L’empoisonnement d’artifacts adopte une approche différente : il vise les artifacts produits par les pipelines de build plutôt que leurs entrées. Les attaquants qui obtiennent l’accès au stockage d’artifacts (registres de conteneurs, dépôts de packages, stockage de binaires) peuvent remplacer des artifacts légitimes par des versions dotées de portes dérobées. C’est particulièrement efficace contre les images de conteneurs stockées dans des registres à tags mutables — un attaquant qui obtient un accès en écriture peut remplacer l’image derrière un tag :latest ou :v1.2.3 sans changer le tag lui-même.

Pour une exploration approfondie de ces vecteurs d’attaque et de leurs défenses, consultez : Confusion de dépendances et empoisonnement d’artifacts : attaques et défenses.

Vol d’identifiants et exfiltration de secrets

Les pipelines CI/CD sont de véritables trésors d’identifiants. Ils ont besoin d’accéder aux dépôts de code source, aux fournisseurs cloud, aux registres de conteneurs, aux bases de données, aux cibles de déploiement et aux services externes. Ces identifiants — clés API, tokens, mots de passe, certificats et clés de signature — sont la cible principale de nombreuses attaques CI/CD.

Techniques courantes d’exfiltration de secrets

Les attaquants recourent à diverses techniques pour dérober les secrets des environnements CI/CD :

• Dump des variables d’environnement : De nombreux systèmes CI/CD injectent les secrets sous forme de variables d’environnement. Une simple commande env ou printenv dans une étape de pipeline compromise révèle tous les secrets disponibles.
• Balayage du système de fichiers : Les secrets peuvent être écrits sur le disque sous forme de fichiers (par ex., ~/.docker/config.json, ~/.aws/credentials, ~/.kube/config). Les attaquants parcourent le système de fichiers à la recherche de fichiers d’identifiants.
• Inspection de la mémoire : Sur les runners auto-hébergés, les attaquants peuvent inspecter la mémoire des processus ou /proc pour trouver les secrets déchiffrés au moment de l’exécution.
• Interception réseau : Si les pipelines communiquent avec des services via des canaux non chiffrés, des attaquants disposant d’un accès réseau peuvent intercepter les identifiants en transit.
• Exfiltration via les logs : Les secrets qui apparaissent accidentellement dans les logs de build (un phénomène malheureusement très courant) peuvent être extraits par quiconque a accès aux logs.
• Exfiltration via DNS/HTTP : Dans les environnements restreints où les connexions sortantes sont limitées, les attaquants encodent les secrets dérobés dans des requêtes DNS ou des en-têtes HTTP pour contourner les contrôles de sortie.

Le problème cumulatif de la prolifération des identifiants

Un défi majeur de la sécurité CI/CD est la prolifération des identifiants (credential sprawl) — la tendance des secrets à s’accumuler au fil du temps dans les configurations de pipeline, les variables d’environnement, les coffres de secrets et les fichiers de configuration. Les identifiants à longue durée de vie jamais renouvelés, les comptes de service trop permissifs et les secrets partagés entre plusieurs pipelines augmentent tous le rayon d’impact d’un vol d’identifiants.

La solution est une approche rigoureuse de la gestion des secrets, combinant identifiants à courte durée de vie, accès au moindre privilège, rotation des secrets et injection au moment de l’exécution depuis un coffre centralisé. Pour des conseils de mise en œuvre détaillés, consultez notre guide sur la Gestion des secrets dans les pipelines CI/CD : patterns avec Vault.

Pour vous exercer à détecter et prévenir les fuites de secrets dans un environnement contrôlé, suivez notre lab pratique : Lab : détecter et prévenir les fuites de secrets dans les pipelines CI/CD.

Altération d’artifacts et attaques de registres

L’intégrité des artifacts est une pierre angulaire de la sécurité de la chaîne d’approvisionnement. Si un attaquant peut modifier les artifacts que votre pipeline produit — images de conteneurs, packages, binaires ou manifestes de déploiement — il peut injecter du code malveillant qui se propage à chaque environnement consommant ces artifacts.

Attaques par mutation de tags

Les registres de conteneurs autorisent par défaut l’écrasement des tags d’images. Un attaquant disposant d’un accès en écriture à un registre peut remplacer l’image derrière n’importe quel tag mutable (comme :latest, :stable, ou même un tag de version en apparence spécifique comme :v2.1.0) par une version dotée d’une porte dérobée. Les systèmes en aval qui récupèrent ce tag recevront silencieusement l’image compromise.

C’est pourquoi les tags immuables et les références par digest (image@sha256:abc123...) sont des contrôles de sécurité essentiels. Les mécanismes de confiance de contenu comme Docker Content Trust (DCT) et Sigstore/cosign fournissent une vérification cryptographique de la provenance des images.

Compromission de registre

La compromission directe des registres d’artifacts — que ce soit via des identifiants dérobés, l’exploitation de vulnérabilités du registre ou des menaces internes — donne aux attaquants la capacité de modifier n’importe quel artifact stocké. Les registres auto-hébergés dépourvus d’authentification, utilisant des identifiants par défaut ou exécutant des logiciels non corrigés sont particulièrement vulnérables.

Manipulation du processus de build

Plutôt que d’altérer les artifacts après leur construction, les attaquants sophistiqués modifient le processus de build lui-même pour produire des artifacts compromis. Cela peut impliquer la manipulation de Dockerfiles, l’injection de couches malveillantes dans des builds multi-étapes ou la modification des options de compilation pour insérer des portes dérobées. Ces attaques sont particulièrement insidieuses car les artifacts obtenus semblent être des produits légitimes du pipeline CI/CD.

Se défendre contre l’altération d’artifacts exige une combinaison de stockage immuable, de signature cryptographique, d’attestation de provenance (comme SLSA) et de vérification continue. Pour vous exercer à détecter l’altération d’artifacts dans un environnement pratique, consultez : Lab : détection d’altération d’artifacts — remplacement d’images de conteneurs dans un registre.

Actions et intégrations tierces compromises

Les pipelines CI/CD modernes ne sont pas monolithiques — ils sont assemblés à partir de dizaines de composants tiers : GitHub Actions, templates GitLab CI, plugins Jenkins, providers Terraform et diverses intégrations SaaS. Chacun de ces composants représente une frontière de confiance que les attaquants peuvent exploiter.

Attaques de la chaîne d’approvisionnement via GitHub Actions

Les GitHub Actions sont une cible de choix car elles exécutent du code arbitraire dans le contexte du workflow qui les appelle. Les vecteurs d’attaque incluent :

• Dépôts d’actions compromis : Un attaquant qui obtient l’accès au dépôt d’une action populaire peut pousser du code malveillant qui s’exécute dans chaque workflow utilisant cette action. L’incident tj-actions/changed-files en 2023 l’a démontré à grande échelle.
• Manipulation de tags : Les actions référencées par des tags mutables (par ex., @v3) peuvent être remplacées silencieusement. L’attaquant déplace le tag pour qu’il pointe vers un commit malveillant.
• Typosquatting : Des actions malveillantes publiées sous des noms proches de ceux d’actions populaires exploitent les fautes de frappe des développeurs.
• Reprise d’actions abandonnées : Lorsque les mainteneurs d’une action abandonnent leur projet, des attaquants peuvent parfois s’emparer de l’espace de noms et pousser des mises à jour malveillantes.

Risques liés aux plugins et extensions

Les plugins Jenkins, les composants GitLab CI et d’autres extensions CI/CD présentent des risques similaires. De nombreux plugins sont maintenus par des contributeurs individuels aux pratiques de sécurité variables. Les vulnérabilités des plugins peuvent exposer toute l’infrastructure CI/CD ; les plugins Jenkins ont historiquement été une source abondante de vols d’identifiants et de vulnérabilités d’exécution de code à distance.

La stratégie défensive consiste à épingler tous les composants tiers à des références immuables (SHA de commit plutôt que tags), à auditer régulièrement les dépendances et à utiliser des outils qui détectent les actions connues comme malveillantes. Pour vous exercer à détecter des GitHub Actions malveillantes, suivez : Lab : détecter les GitHub Actions malveillantes par analyse statique.

Chronologie des attaques CI/CD réelles

La chronologie suivante retrace les principales attaques CI/CD et de la chaîne d’approvisionnement logicielle de 2020 à 2024. Chaque incident illustre différents vecteurs d’attaque et rappelle pourquoi la sécurité CI/CD mérite une attention dédiée.

SolarWinds / SUNBURST (décembre 2020)

L’attaque SolarWinds demeure la compromission de la chaîne d’approvisionnement CI/CD de référence. Les attaquants (attribués au SVR, le service de renseignement russe) ont infiltré l’infrastructure de build de SolarWinds et injecté la porte dérobée SUNBURST dans le processus de mise à jour du logiciel Orion. Le pipeline de build compromis a produit des mises à jour trojanisées distribuées à environ 18 000 organisations, dont des agences gouvernementales américaines, des entreprises du Fortune 500 et des opérateurs d’infrastructures critiques.

Leçons clés : L’infrastructure de build doit être traitée comme un actif critique. La vérification de l’intégrité des artifacts et les builds reproductibles auraient pu détecter l’altération. L’attaque a démontré que compromettre un seul pipeline de build peut avoir un impact de niveau étatique.

Codecov Bash Uploader (janvier–avril 2021)

Les attaquants ont compromis le script Bash Uploader de Codecov — un composant utilisé par des milliers de pipelines CI/CD pour téléverser des rapports de couverture de code. Pendant trois mois, le script modifié a exfiltré les variables d’environnement (dont les secrets, tokens et clés CI/CD) de chaque pipeline qui l’exécutait. L’attaque a touché des entreprises comme Twitch, HashiCorp, Confluent et bien d’autres.

Leçons clés : Les scripts tiers exécutés dans les pipelines doivent voir leur intégrité vérifiée (par ex. via des sommes de contrôle). Les secrets ne devraient jamais être largement disponibles sous forme de variables d’environnement. Une surveillance du trafic sortant sur les runners CI/CD aurait pu détecter l’exfiltration.

Détournement de ua-parser-js (octobre 2021)

Le package npm ua-parser-js, téléchargé plus de 7 millions de fois par semaine, a été détourné lorsque le compte npm du mainteneur a été compromis. Des versions malveillantes ont été publiées, installant des cryptomineurs et des malwares voleurs d’identifiants. Comme ce package est une dépendance de milliers d’autres packages et processus de build CI/CD, le rayon d’impact a été énorme.

Leçons clés : Même des packages de confiance et largement utilisés peuvent être compromis. Les lock files, la vérification d’intégrité et l’analyse automatisée des dépendances en CI/CD sont essentiels. La sécurité des comptes npm (2FA, limitation de portée des tokens) est un enjeu de chaîne d’approvisionnement.

Incident de sécurité CircleCI (janvier 2023)

CircleCI, l’une des plus grandes plateformes CI/CD, a révélé qu’un attaquant avait obtenu l’accès à des données clients, dont des variables d’environnement, des clés et des tokens stockés dans CircleCI. La brèche provenait d’un malware sur l’ordinateur portable d’un ingénieur, qui a dérobé un token de session SSO valide, ensuite utilisé pour accéder aux systèmes internes. CircleCI a exhorté tous ses clients à renouveler immédiatement chaque secret stocké sur la plateforme.

Leçons clés : Les fournisseurs de plateformes CI/CD sont des cibles de grande valeur. Les organisations doivent mettre en œuvre une défense en profondeur et ne pas se reposer uniquement sur la sécurité de leur plateforme CI/CD. Des identifiants à courte durée de vie et à portée limitée réduisent l’impact des compromissions de plateforme. Disposer d’un plan de réponse aux incidents pour la rotation des secrets est essentiel.

Compromission de tj-actions/changed-files (mars 2023)

La populaire GitHub Action tj-actions/changed-files (utilisée par plus de 23 000 dépôts) a été compromise lorsqu’un attaquant a obtenu l’accès au compte du mainteneur et poussé du code malveillant. L’action compromise a déversé les secrets CI/CD dans les logs des workflows, où ils pouvaient être récoltés. Comme de nombreux workflows référençaient l’action par des tags de version mutables, le code malveillant a été automatiquement intégré à des milliers d’exécutions de pipeline.

Leçons clés : Épinglez toujours les GitHub Actions à des SHA de commit, jamais à des tags de version. Surveillez les dépendances d’actions pour repérer tout changement inattendu. Appliquez aux workflows des permissions suivant le principe du moindre privilège.

Porte dérobée XZ Utils (mars 2024)

La porte dérobée XZ Utils (CVE-2024-3094) a été une attaque de la chaîne d’approvisionnement sophistiquée, étalée sur plusieurs années. Un contributeur qui avait bâti sa crédibilité au sein du projet XZ pendant deux ans a introduit progressivement une porte dérobée dans le système de build. Le code malveillant était caché dans des fichiers de fixtures de test et activé par des scripts de build soigneusement conçus — un exemple d’école d’exécution de pipeline empoisonné indirecte. La porte dérobée visait le démon SSH des systèmes Linux et aurait affecté quasiment toutes les distributions Linux si elle n’avait pas été découverte par hasard.

Leçons clés : L’ingénierie sociale et l’infiltration de longue durée des projets open source sont des menaces réelles. L’intégrité du système de build est aussi importante que celle du code source. L’attaque a démontré que les techniques d’I-PPE peuvent être extraordinairement subtiles et patientes.

Patterns défensifs et mesures d’atténuation

Se défendre contre les attaques CI/CD exige une approche en couches qui traite chaque catégorie d’attaque. Les patterns suivants forment le socle d’une posture de sécurité CI/CD robuste.

Configuration de pipeline en tant que code, avec des contrôles stricts

• Protéger les fichiers de configuration de pipeline avec CODEOWNERS et des règles de protection de branche
• Exiger une revue de code pour toute modification de la configuration CI/CD
• Utiliser des templates de pipeline gérés de façon centralisée plutôt que des configurations propres à chaque dépôt lorsque c’est possible
• Séparer les définitions de pipeline du code applicatif dans les dépôts sensibles

Durcissement des identifiants

• Utiliser des identifiants à courte durée de vie et à portée limitée (fédération OIDC avec les fournisseurs cloud)
• Mettre en œuvre une injection de secrets juste-à-temps depuis un coffre centralisé
• Ne jamais exposer les secrets sous forme de variables d’environnement quand une injection par fichier est possible
• Renouveler tous les identifiants selon un calendrier défini et immédiatement après tout incident
• Mettre en œuvre le secret scanning dans les logs CI/CD et les artifacts produits

Contrôles des dépendances et de la chaîne d’approvisionnement

• Épingler toutes les dépendances à des versions exactes avec des hachages d’intégrité
• Utiliser des proxys de registre privé avec limitation d’espace de noms pour prévenir la confusion de dépendances
• Épingler les GitHub Actions et autres composants de pipeline tiers à des SHA de commit
• Mettre en œuvre une analyse automatisée des vulnérabilités des dépendances dans chaque pipeline
• Générer et vérifier des nomenclatures logicielles (SBOM)

Intégrité des artifacts

• Signer cryptographiquement tous les artifacts de build (Sigstore/cosign pour les conteneurs, GPG pour les packages)
• Utiliser des tags immuables et des références par digest pour les images de conteneurs
• Mettre en œuvre l’attestation de provenance SLSA pour vérifier l’origine des artifacts
• Déployer des contrôleurs d’admission (par ex. Kyverno, OPA Gatekeeper) qui vérifient les signatures avant le déploiement

Surveillance et détection

• Surveiller l’exécution des pipelines à la recherche de comportements anormaux (connexions réseau inattendues, accès au système de fichiers, jobs de longue durée)
• Mettre en œuvre des contrôles de sortie sur les runners CI/CD pour détecter l’exfiltration
• Auditer toutes les modifications des configurations de pipeline, des secrets et des permissions
• Corréler les événements CI/CD avec un SIEM pour une détection inter-systèmes

Pour une analyse approfondie de chacun de ces patterns défensifs avec des exemples de mise en œuvre, consultez : Patterns défensifs et mesures d’atténuation pour les attaques de pipelines CI/CD.

Modélisation des menaces pour le CI/CD

Une sécurité CI/CD efficace commence par la modélisation des menaces — l’identification systématique des frontières de confiance, des flux de données et des chemins d’attaque au sein de votre architecture de pipeline. Sans une compréhension claire de votre modèle de menaces CI/CD, les efforts défensifs tendent à être réactifs et incomplets.

Frontières de confiance clés à évaluer

Chaque système CI/CD comporte des frontières de confiance que les attaquants tentent de franchir :

• Du poste de travail du développeur au dépôt : Une machine de développeur compromise peut-elle pousser du code malveillant ?
• Du dépôt au pipeline : Quels changements déclenchent l’exécution du pipeline, et avec quels privilèges ?
• Du pipeline au coffre de secrets : Quels pipelines peuvent accéder à quels secrets, et sous quelles conditions ?
• Du pipeline au registre d’artifacts : Qui peut pousser des artifacts, et sont-ils vérifiés avant utilisation ?
• Du registre d’artifacts au déploiement : Les artifacts déployés sont-ils vérifiés par rapport à leur provenance de build ?
• Des services tiers au pipeline : De quels accès disposent les intégrations externes ?

Analyse des chemins d’attaque

Une fois les frontières de confiance cartographiées, l’étape suivante consiste à énumérer les chemins d’attaque — les séquences d’actions qu’un attaquant pourrait entreprendre pour atteindre ses objectifs. Les objectifs courants incluent :

• Injecter du code malveillant dans les déploiements de production
• Exfiltrer des identifiants en vue d’un mouvement latéral
• Établir une persistance dans l’infrastructure CI/CD
• Perturber la livraison logicielle (sabotage/déni de service)
• Compromettre les consommateurs en aval par propagation dans la chaîne d’approvisionnement

Pour un guide complet de la modélisation des menaces CI/CD avec des cadres et modèles pratiques, consultez : Modélisation des menaces CI/CD : frontières de confiance et chemins d’attaque.

Labs pratiques : s’exercer à l’attaque et à la défense

Comprendre les attaques CI/CD en théorie est important, mais rien ne remplace la pratique. Les labs suivants offrent des environnements contrôlés où vous pouvez explorer en toute sécurité les techniques d’attaque et mettre en œuvre des défenses :

• Lab : exploiter et se défendre contre l’exécution de pipeline empoisonné (PPE) — Pratiquez les attaques PPE directes et indirectes, puis mettez en œuvre la protection de branche, CODEOWNERS et des contrôles de configuration de pipeline pour vous en défendre.
• Lab : confusion de dépendances et empoisonnement d’artifacts — Exécutez une attaque par confusion de dépendances contre une configuration de build vulnérable, puis mettez en œuvre la limitation d’espace de noms, la vérification d’intégrité et des contrôles de registre privé.
• Lab : détecter et prévenir les fuites de secrets dans les pipelines CI/CD — Découvrez des secrets exposés via des variables d’environnement, des logs et des artifacts, puis mettez en place une détection avec des outils comme gitleaks, truffleHog et des gardes de pipeline personnalisés.
• Lab : détection d’altération d’artifacts — remplacement d’images de conteneurs dans un registre — Réalisez une attaque par mutation de tag contre un registre de conteneurs, puis mettez en œuvre la confiance de contenu, l’épinglage par digest et la vérification par contrôleur d’admission.
• Lab : détecter les GitHub Actions malveillantes par analyse statique — Analysez des GitHub Actions à la recherche de patterns malveillants, mettez en œuvre l’épinglage par SHA et intégrez une détection automatisée à votre processus d’approbation de workflow.

Chaque lab comprend des instructions pas à pas, un environnement préconfiguré et des scénarios d’attaque comme de défense. Ils sont conçus pour être réalisés indépendamment, même si les parcourir dans l’ordre indiqué ci-dessus construira une compréhension complète de la sécurité CI/CD.

Conclusion : bâtir une architecture CI/CD défendable

Les pipelines CI/CD sont devenus la surface d’attaque la plus lourde de conséquences des organisations logicielles modernes. Les incidents recensés dans ce guide — de SolarWinds à XZ Utils — démontrent que les attaquants ont pris conscience de cette réalité et investissent des ressources considérables dans les techniques d’exploitation CI/CD.

Mais le tableau n’est pas entièrement sombre. La communauté de la sécurité CI/CD a réagi avec des référentiels (OWASP CI/CD Top 10, SLSA), des outils (Sigstore, gitleaks, StepSecurity) et des patterns architecturaux qui peuvent réduire considérablement votre exposition. Les principes clés à retenir sont les suivants :

1. Traitez les pipelines comme de l’infrastructure de production. Appliquez au CI/CD la même rigueur de sécurité qu’aux systèmes de production : accès au moindre privilège, surveillance, application des correctifs et réponse aux incidents.
2. Éliminez la confiance implicite. Vérifiez tout — dépendances, actions tierces, artifacts et configurations de pipeline. Épinglez à des références immuables. Signez et vérifiez à chaque étape.
3. Réduisez le rayon d’impact. Utilisez des identifiants à courte durée de vie, des permissions à portée limitée, des runners isolés et une segmentation réseau pour limiter ce qu’un attaquant peut accomplir à partir d’une seule compromission.
4. Investissez dans la visibilité. On ne peut pas défendre ce que l’on ne voit pas. Une journalisation, une surveillance et des alertes complètes pour les systèmes CI/CD sont non négociables.
5. Entraînez votre réponse. Utilisez les labs référencés tout au long de ce guide pour développer des automatismes, tant pour la détection des attaques que pour la mise en œuvre des défenses. Lorsque le prochain incident CI/CD surviendra, vous serez prêt.

La sécurité CI/CD n’est pas un projet ponctuel — c’est une discipline continue qui doit évoluer à mesure que les techniques d’attaque progressent. Commencez par un modèle de menaces, mettez en œuvre les patterns défensifs qui répondent à vos risques les plus élevés, et validez continuellement vos défenses grâce aux labs pratiques ci-dessus. Vos pipelines sont trop importants pour rester sans défense.