CI/CD sous attaque : pourquoi votre pipeline est devenu la cible n°1 des APT

CVE-2026-63077 dans JetBrains TeamCity. CVE-2024-27198 dans TeamCity encore. La compromission de SolarWinds Orion en 2020. Trois incidents séparés par plusieurs années, un seul dénominateur commun : le pipeline CI/CD. Ce n'est pas une coïncidence, c'est un pattern. Et si votre pipeline de déploiement n'est pas au centre de votre stratégie de sécurité, vous avez un angle mort qui coûtera cher.

Pourquoi le pipeline CI/CD est une cible idéale pour les groupes APT

Posez-vous la question suivante : dans votre organisation, quel est le système qui a simultanément accès en lecture à l'intégralité du code source, exécute des commandes avec des privilèges élevés sur vos serveurs, génère et publie les artefacts logiciels qui partent en production, stocke des credentials d'infrastructure, et est souvent opéré par les équipes les moins exposées aux formations sécurité ? La réponse est presque universellement la même : votre serveur CI/CD.

Pour un attaquant cherchant à s'introduire discrètement dans une organisation ou à mener une attaque de supply chain, le serveur CI/CD représente un point de levier exceptionnel. Compromettez-le, et vous pouvez potentiellement atteindre plusieurs objectifs simultanément : exfiltrer le code source (propriété intellectuelle, logique métier, algorithmes propriétaires), accéder aux secrets d'infrastructure qui pullulent dans les pipelines (clés SSH, tokens API, credentials de bases de données, certificats de signature), injecter du code malveillant dans les builds avant leur déploiement en production, et maintenir une présence persistante dans l'organisation tout en restant largement invisible dans les logs applicatifs habituellement surveillés.

Ce n'est pas anecdotique. Selon le rapport annuel de Palo Alto Networks Unit 42 sur les menaces en 2025, les attaques ciblant les outils DevOps ont augmenté de 312 % entre 2022 et 2025. JetBrains TeamCity, Jenkins, GitHub Actions, GitLab CI, CircleCI, Bamboo, Azure DevOps — tous ont été affectés par des vulnérabilités critiques activement exploitées au cours des trois dernières années. Et la liste des acteurs qui exploitent ces vulnérabilités inclut les noms les plus sérieux du paysage des menaces : APT29 (Cozy Bear, affilié au SVR russe), APT38 (Lazarus Group, Corée du Nord), TA505, et plusieurs opérateurs ransomware de premier plan.

La position stratégique du CI/CD dans l'architecture moderne est encore renforcée par la tendance au "tout pipeline" : aujourd'hui, les organisations font tourner sur leurs serveurs de build non seulement la compilation du code, mais aussi le provisioning d'infrastructure (Terraform, Pulumi, CloudFormation), les déploiements Kubernetes, les scans de sécurité, les mises à jour de dépendances, la gestion des secrets. Le rayon d'action d'un attaquant ayant compromis un serveur CI/CD ne cesse de s'étendre à mesure que les pipelines deviennent plus sophistiqués et plus intégrés.

Il y a également un facteur humain structurel : les équipes DevOps ont une culture "move fast" qui entre parfois en tension avec la rigueur sécurité. Les secrets en clair dans les fichiers de configuration de pipeline, les permissions trop larges des service accounts, les dépendances tierces installées sans vérification, les runners CI exposés sur Internet sans protection — ces pratiques sont systématiques et documentées dans des centaines d'incidents. Elles ne sont pas dues à de la négligence individuelle, mais à une architecture sécurité qui n'a pas suivi la vitesse d'adoption du DevOps dans les organisations.

Un dernier facteur aggravant : la confiance implicite accordée aux artefacts produits par le CI/CD. Un binaire ou une image Docker qui sort du pipeline de build est typiquement considéré comme "de confiance" par les équipes de déploiement et les systèmes de production. Cette confiance, souvent non vérifiée cryptographiquement, est précisément ce que les attaquants exploitent lorsqu'ils injectent du code dans les builds : leurs modifications héritent automatiquement de la légitimité du pipeline.

Le pattern se répète : de SolarWinds (2020) à TeamCity (2026)

SolarWinds Orion (décembre 2020) est l'attaque fondatrice qui a mis le sujet sur la carte. Le groupe APT29 a compromis l'environnement de build de SolarWinds et injecté une backdoor — SUNBURST — dans les mises à jour de l'outil de supervision réseau Orion. Résultat : 18 000 organisations clientes ont téléchargé et installé des mises à jour légitimes, signées numériquement, contenant un malware. Les victims identifiées incluaient des agences gouvernementales américaines (Treasury, Commerce, State Department, DHS), des entreprises Fortune 500 et des prestataires de défense. L'investigation a duré des mois, et certaines compromissions ont mis plus d'un an à être pleinement caractérisées.

Ce qui rend SolarWinds fondateur, c'est la démonstration d'un principe : il est plus efficace de compromettre l'outil qui produit le logiciel que d'attaquer le logiciel lui-même ou ses utilisateurs finaux. La contamination est automatique, massive, et bénéficie de la signature numérique légitime du vendeur. 18 000 organisations ont été exposées par une seule compromission initiale.

En mars 2024, CVE-2024-27198 et CVE-2024-27199 ont affecté JetBrains TeamCity. Deux vulnérabilités de contournement d'authentification ont été massivement exploitées par APT29 et d'autres groupes APT russes pour compromettre des serveurs TeamCity d'entreprises occidentales dans les secteurs de la technologie, de l'énergie et de la défense. L'objectif documenté incluait l'espionnage économique et l'implantation de backdoors persistantes permettant des accès ultérieurs. Le Gouvernement britannique et la CISA avaient publié des alertes conjointes sur ces exploitations.

En août 2024, l'environnement CI/CD de CircleCI a subi un incident exposant des secrets clients stockés dans les pipelines — tokens AWS/Azure/GCP, clés SSH, API keys. Des milliers d'organisations ont dû révoquer en urgence l'ensemble de leurs credentials CI/CD, en aval d'une compromission sur laquelle CircleCI a mis plusieurs semaines à communiquer complètement. L'incident a mis en lumière les risques spécifiques des plateformes CI/CD SaaS : en mutualisant les pipelines de milliers d'organisations sur une même infrastructure, une compromission unique affecte potentiellement tous les clients.

En juillet 2025, une attaque supply chain via un package npm compromis a affecté plus de 400 projets JavaScript. Un compte développeur compromis a été utilisé pour publier une version malveillante d'un package populaire. Les pipelines CI/CD qui installaient automatiquement les nouvelles versions du package ont été les premiers vecteurs de propagation — encore une fois, la confiance implicite accordée aux pipelines a amplifié l'attaque.

Et en juillet-août 2026, CVE-2026-63077 dans JetBrains TeamCity. Deuxième vulnérabilité critique majeure dans TeamCity en moins de 30 mois. CVSS 9.8, exploitation active confirmée par la CISA, ajout au catalogue KEV avec un délai de patch record de 3 jours pour les agences fédérales. Le cycle recommence avec une précision troublante.

Le point commun de tous ces incidents : des organisations ayant des outils de sécurité robustes sur leurs endpoints, leurs périmètres réseau, leurs applications web — mais qui avaient traité leur pipeline CI/CD comme une infrastructure de second rang, moins critique, moins surveillée, moins patchée. C'est exactement là que les attaquants ont frappé, à chaque fois.

Anatomie d'une attaque CI/CD : le déroulement concret

Pour comprendre pourquoi les pipelines CI/CD sont si attractifs pour des attaquants sophistiqués, il faut comprendre comment une attaque se déroule en pratique. Voici le schéma type observé dans les incidents les plus documentés de ces trois dernières années.

Phase 1 — Accès initial. L'attaquant obtient un accès au serveur CI/CD, soit via une vulnérabilité du logiciel lui-même (CVE-2026-63077, CVE-2024-27198), soit via des credentials volés (phishing d'un développeur, bruteforce d'un compte non protégé par MFA), soit via un token CI/CD exfiltré d'un repository Git (les tokens de webhook, de déploiement ou d'intégration se retrouvent fréquemment dans des repositories publics ou semi-publics). Dans le cas de CVE-2026-63077, cette phase ne demande que quelques secondes et aucune authentification.

Phase 2 — Collecte de secrets. Une fois sur le serveur, l'attaquant accède aux variables d'environnement et aux secret stores du CI/CD. C'est là que se concentrent les ressources stratégiques : tokens AWS/Azure/GCP avec des permissions larges, clés SSH vers les serveurs de production, credentials de bases de données, API keys de services tiers, certificats de signature de code. Dans les audits CI/CD que je conduis, je trouve en moyenne 40 à 100 secrets distincts dans l'environnement d'une organisation de taille moyenne — souvent beaucoup plus que les équipes n'en ont conscience.

Phase 3 — Mouvement latéral. Armé des secrets collectés, l'attaquant peut se déplacer vers d'autres systèmes : environnements cloud AWS/Azure/GCP, registres de containers (ECR, GCR, Docker Hub privé), clusters Kubernetes, dépôts de code privés, outils de monitoring. La compromission du CI/CD ouvre souvent un accès quasi direct à la production — c'est par design que le serveur de build peut déployer vers la production.

Phase 4 — Injection dans la supply chain. Si l'objectif est une attaque supply chain ou un accès persistant discret, l'attaquant modifie les scripts de build pour injecter du code malveillant dans les artefacts produits : binaires exécutables, images Docker, packages npm/Maven/PyPI. Cette modification peut être extrêmement subtile — quelques lignes dans un script de post-processing, une dépendance remplacée par une version légèrement modifiée. Les artefacts produits héritent de la signature numérique du pipeline, leur donnant une apparence totale de légitimité.

Phase 5 — Persistance et exfiltration longue durée. L'attaquant installe une backdoor sur le serveur CI/CD (souvent via modification des scripts de build ou d'initialisation des agents), modifie la configuration du pipeline pour garantir un accès futur, ou met en place une exfiltration progressive de code source et de données sensibles. Dans les cas les plus sophistiqués documentés (APT29 dans les incidents TeamCity 2024), cette phase a duré plusieurs mois avant détection — le serveur CI/CD étant rarement surveillé avec la même rigueur que les systèmes de production.

Ce que les organisations font systématiquement mal

Au fil des audits et des missions d'incident response sur des environnements CI/CD, j'observe les mêmes erreurs récurrentes, indépendamment du secteur ou de la taille de l'organisation. Ces patterns ne sont pas anodins — ils expliquent pourquoi les attaques CI/CD continuent de réussir malgré la documentation abondante des incidents précédents.

Exposition Internet sans nécessité. Un nombre significatif d'organisations exposent leur serveur CI/CD directement sur Internet, souvent pour des raisons de praticité (webhooks GitHub/GitLab, développeurs en télétravail, intégration avec des services cloud). Cette exposition est rarement indispensable — un VPN ou une solution ZTNA couvre généralement le besoin légitime — mais elle multiplie la surface d'attaque de façon considérable. Chaque vulnérabilité critique publiée dans TeamCity ou Jenkins devient immédiatement exploitable depuis n'importe quelle adresse IP dans le monde.

Secrets en clair dans les pipelines et l'historique Git. Malgré des années de sensibilisation, trouver des secrets en clair dans des fichiers de configuration de pipeline (.jenkinsfile, .gitlab-ci.yml, .circleci/config.yml) ou dans l'historique Git reste d'une fréquence alarmante. Un secret commis dans Git, même supprimé ensuite, reste accessible dans l'historique. L'utilisation d'un gestionnaire de secrets centralisé (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Doppler) avec injection dynamique à l'exécution est la pratique correcte, mais elle demande un effort d'architecture que beaucoup d'équipes reportent indéfiniment.

Permissions trop larges des service accounts CI/CD. Le service account utilisé par le pipeline pour déployer vers la production a souvent des droits administrateur sur l'ensemble de l'infrastructure cloud, hérités d'une époque où "ça marchait ainsi et personne n'a reposé la question". Le principe du moindre privilège s'applique très rarement aux pipelines dans la pratique : un pipeline qui déploie sur un cluster Kubernetes spécifique n'a besoin que de droits sur ce namespace, pas d'un admin AWS au périmètre illimité avec permissions sur tous les services et toutes les régions.

Absence de surveillance des événements CI/CD. Les logs des outils CI/CD sont rarement intégrés dans le SIEM de l'organisation. Les alertes sur des événements suspects — connexions administrateur depuis des IP non habituelles, modifications de configurations de pipeline, accès aux secrets hors des fenêtres de build normales, création de nouveaux comptes ou webhooks — n'existent simplement pas. La détection d'une compromission repose alors sur des alertes aval (comportement anormal en production, détection EDR sur un serveur cible) plutôt que sur une détection précoce au niveau du CI/CD, ce qui signifie que l'attaquant a eu le temps d'opérer pendant des jours ou des semaines.

Mises à jour différées. Les outils CI/CD sont traités comme des "outils internes" et soumis à des cycles de mise à jour bien plus longs que les applications exposées en production. J'ai vu des Jenkins en version 2.x.y datant de trois ans, des TeamCity avec des années de retard de correctifs. Les équipes rationalisent ce retard par la peur de la régression ("on ne touche pas à ce qui marche"). Or, comme CVE-2026-63077 et ses prédécesseurs le démontrent, la criticité des vulnérabilités dans ces outils est réelle et l'exploitation rapide — parfois en moins de 72 heures après la publication du patch.

Absence de vérification des dépendances. Les pipelines installent automatiquement des dépendances depuis des registres publics (npm, PyPI, Maven Central, Docker Hub) souvent sans vérification de hash ou de signature. Les attaques de type dependency confusion — publier un package public avec le même nom qu'un package interne privé et un numéro de version plus élevé — et les attaques de typosquatting restent efficaces en 2026. Plusieurs incidents documentés cette année impliquent des packages malveillants installés automatiquement par des pipelines CI sans mécanisme de vérification d'intégrité.

Comment sécuriser son pipeline CI/CD — approche par niveaux

La bonne nouvelle : sécuriser correctement un pipeline CI/CD n'est pas une question de budget exorbitant — c'est une question de priorité, de méthode, et d'un peu de discipline architecturale. Voici mon approche par niveaux, du plus fondamental au plus avancé.

Niveau 1 — Hygiène de base (cette semaine). Commencez par ne plus exposer votre serveur CI/CD directement sur Internet sans protection. Si vos développeurs ont besoin d'y accéder en télétravail, déployez un accès VPN ou une solution ZTNA devant lui — c'est une journée de travail pour réduire massivement votre surface d'attaque. Ensuite, activez le MFA sur tous les comptes administrateur du CI/CD — sans exception. Enfin, intégrez votre outil CI/CD dans votre processus de patch management : les mises à jour de sécurité doivent être appliquées dans les 48 à 72 heures suivant la publication pour les vulnérabilités critiques.

Niveau 2 — Gestion des secrets (dans le mois). Auditez l'ensemble de vos fichiers de configuration de pipeline et votre historique Git pour identifier les secrets en clair — des outils comme truffleHog ou git-secrets facilitent cet audit. Déployez un gestionnaire de secrets centralisé (HashiCorp Vault est open source et performant, les solutions natives cloud sont disponibles sur AWS, Azure, GCP) et migrez tous les secrets vers l'injection dynamique à l'exécution. Configurez des rotations automatiques des credentials CI/CD. Cette étape est la plus impactante en termes de réduction du blast radius d'une compromission : un attaquant qui prend le contrôle du serveur CI/CD mais ne trouve aucun secret en dur est considérablement limité dans ce qu'il peut faire.

Niveau 3 — Moindre privilège et segmentation (dans le trimestre). Appliquez rigoureusement le principe du moindre privilège aux service accounts CI/CD : définissez des permissions spécifiques au périmètre exact nécessaire pour chaque pipeline. Un pipeline de test ne doit avoir aucun droit de déploiement en production. Un pipeline de déploiement en staging ne doit pas avoir accès à la production. Utilisez des agents de build éphémères — containers ou VMs détruits après chaque build — plutôt que des agents persistants. Un agent compromis qui disparaît après le build est infiniment moins dangereux qu'un agent persistant utilisable comme tremplin pendant des mois.

Niveau 4 — Surveillance et détection (à intégrer dans votre SOC). Intégrez les logs de votre serveur CI/CD dans votre SIEM. Définissez des règles d'alerte sur les événements suspects : connexions administrateur depuis des IP non habituelles, modifications de configurations de pipeline hors des fenêtres normales, accès aux secrets en dehors des fenêtres de build, création de nouveaux comptes ou webhooks, téléchargements inhabituels d'artefacts. Mettez en place une vérification d'intégrité des artefacts produits (publication de hash SHA-256 et vérification) et une analyse systématique des images Docker avec un scanner (Trivy, Grype, Snyk Container).

Niveau 5 — Supply chain avancé (pour les organisations à haute maturité). Implémentez le framework SLSA (Supply chain Levels for Software Artifacts), un standard ouvert développé par Google et l'OpenSSF qui définit des niveaux de garantie sur la traçabilité et l'intégrité des artefacts logiciels. Utilisez la technologie Sigstore (Cosign, Rekor, Fulcio) pour la signature cryptographique et la transparence des artefacts. Déployez des hash pins pour les dépendances critiques plutôt que des contraintes de version sémantique. Considérez l'utilisation de SBOM (Software Bill of Materials) pour chaque artefact produit, permettant une réponse rapide en cas de compromission d'une dépendance.

Ces cinq niveaux ne sont pas séquentiels strictement — certaines mesures de niveau 3 ou 4 peuvent être mises en place avant d'avoir complété le niveau 2. L'important est de progresser systématiquement et de ne pas rester bloqué sur "on le fera quand on aura le temps". En matière de CI/CD, le temps passe vite et les vulnérabilités critiques n'attendent pas.

Conclusion

Le pipeline CI/CD est devenu l'artère centrale de la production logicielle moderne. Il concentre les secrets, les accès, les capacités de déploiement, la confiance des équipes. Il est donc logique — et au regard des incidents des cinq dernières années, prévisible — qu'il soit devenu une cible prioritaire pour les groupes APT et les opérateurs ransomware les plus sophistiqués.

De SolarWinds à TeamCity, le schéma d'attaque est documenté, reproductible et récurrent. Les victimes ne sont pas des organisations négligentes ou sous-financées — ce sont des organisations qui avaient de bons contrôles de sécurité sur la plupart de leurs systèmes, mais qui avaient traité leur pipeline CI/CD comme une infrastructure secondaire.

La réponse n'est pas de renoncer à l'automatisation et au DevOps — c'est structurellement impossible et contre-productif. La réponse est d'appliquer à son pipeline CI/CD le même niveau de rigueur sécurité qu'on applique à ses applications de production exposées. Exposition réseau maîtrisée, gestion rigoureuse des secrets, mises à jour systématiques, surveillance active, réduction des privilèges : ces cinq dimensions ne sont pas rocket science. Elles demandent de la rigueur et de la priorité.

CVE-2026-63077 ne sera pas la dernière vulnérabilité critique dans un outil CI/CD en 2026. La suivante arrive. La question est de savoir si votre organisation sera prête cette fois-ci.