CI/CD : vos pipelines de build sont devenus une cible APT

Vos pipelines CI/CD savent tout de votre code, de vos secrets et de vos clés de déploiement. Pendant des années, ils ont constitué l'angle mort parfait : trop techniques pour les équipes sécurité, trop abstraits pour les RSSI, et rarement inclus dans le périmètre des audits. Les groupes APT, eux, l'ont compris depuis longtemps : compromettre un serveur de build vaut infiniment mieux que forcer une porte d'entrée, car il donne accès à l'ensemble des artefacts signés distribués aux clients. La CVE-2026-63077 affectant TeamCity, divulguée le 28 janvier, illustre cette bascule : la sécurité CI/CD n'est plus un sujet d'ingénierie logicielle, c'est un enjeu de défense contre les attaques APT et les compromissions de supply chain. Vos runners, vos secrets et vos registries méritent le même niveau de surveillance que votre Active Directory.

La leçon SolarWinds n'a pas été retenue

En décembre 2020, la révélation de l'opération SolarWinds a changé la façon dont la communauté de sécurité parle de supply chain attacks. L'attaquant — identifié comme le groupe APT29, affilié au SVR russe — n'avait pas piraté directement les 18 000 organisations victimes. Il avait compromis le pipeline de build d'Orion, la plateforme de supervision réseau de SolarWinds, et injecté un backdoor baptisé SUNBURST dans les mises à jour légitimes distribuées aux clients pendant plusieurs mois.

En pratique, les incidents que nous traitons révèlent que l'écart entre politiques de sécurité documentées et application réelle est presque toujours plus grand que prévu. La vérification terrain régulière reste la seule façon de mesurer ce delta.

— Retour terrain, Ayi NEDJIMI Consultants

Ce qui a rendu l'attaque si efficace n'était pas la sophistication du malware. SUNBURST était en réalité assez classique dans ses capacités : commande et contrôle via des requêtes DNS obfusquées, persistance dans le registre Windows, latence volontaire de deux semaines avant activation pour contourner les analyses sandbox post-déploiement. Ce qui l'a rendu dévastateur, c'est son vecteur : il arrivait signé numériquement par SolarWinds, via les canaux de mise à jour officiels, sans aucun indicateur de compromission visible pour les équipes sécurité des victimes. Les défenses classiques — antivirus, EDR, vérification de signature — ne pouvaient rien contre un binaire légitimement signé à partir d'un pipeline de build compromis.

JetBrains TeamCity était associé à cette histoire. Le serveur CI/CD utilisé par SolarWinds pour construire Orion tournait sur TeamCity, même si JetBrains a systématiquement contesté que son produit ait été le vecteur d'entrée initial. L'incident a mis TeamCity — et plus largement la catégorie CI/CD — sous les projecteurs des équipes red team et des agences gouvernementales. Le CISA, le FBI et la NSA ont publié des guidelines spécifiques sur la sécurisation des pipelines CI/CD dans les années qui ont suivi.

Six ans après SolarWinds, CVE-2026-63077 vient rappeler que la leçon n'a pas été retenue à l'échelle de l'industrie. TeamCity présente une nouvelle faille RCE non authentifiée CVSS 9.8 — la troisième critique de ce niveau en trois ans sur ce seul produit. Et selon les données Censys collectées fin juillet 2026, plus de 23 000 instances TeamCity sont accessibles directement depuis Internet sans protection de périmètre. Certaines tournent encore sur des versions de 2019. Dans les entreprises qui les opèrent, ces serveurs sont probablement considérés comme des outils internes sans risque externe particulier. Les groupes APT ont une opinion radicalement différente.

Pourquoi les APT ciblent vos builds en priorité

Pour un attaquant étatique ou un groupe criminel sophistiqué, le serveur CI/CD représente le Graal : accès aux secrets, levier sur la production, et persistance quasi indétectable. Voici les raisons précises pour lesquelles c'est une cible de choix.

L'accès aux secrets. Un serveur TeamCity, Jenkins ou GitHub Actions Runner typique d'une entreprise moyenne stocke entre 50 et 200 secrets opérationnels : clés d'API AWS, Azure et GCP, tokens d'accès GitHub et GitLab, credentials de bases de données de staging et de production, clés de signature de code, tokens d'accès aux registres Docker, identifiants de déploiement sur Kubernetes, clés SSH. Ces secrets sont là parce qu'ils sont nécessaires pour que les builds fonctionnent automatiquement. Un attaquant qui accède au serveur CI/CD les récupère tous en quelques minutes en lisant les variables d'environnement ou les fichiers de configuration des pipelines. Le pivot vers les environnements de production devient alors trivial.

La persistance silencieuse. Injecter un backdoor dans un pipeline de build est une forme de persistance particulièrement difficile à détecter. Le code malveillant est compilé avec le code légitime, signé avec les certificats de production, et distribué via les mécanismes de déploiement habituels. Les défenses classiques ne détectent pas un backdoor injecté au niveau du build, car le binaire final est signé à partir d'une source compromise mais considérée comme légitime par tous les systèmes de contrôle. Il faut une comparaison déterministe entre le code source git et le binaire produit (reproductible builds) pour détecter ce type d'injection a posteriori — et très peu d'organisations l'ont mis en place.

La propagation en aval. Un serveur CI/CD déploie vers les environnements de staging et de production. Un attaquant qui en prend le contrôle peut modifier les scripts de déploiement pour exfiltrer des données en production, installer des outils de reconnaissance sur les serveurs cibles, créer des comptes admin cachés, ou cartographier l'intégralité de l'infrastructure à travers les connexions que le pipeline établit avec ses systèmes de destination. C'est une latéralisation gratuite vers tout système que le pipeline a besoin d'atteindre — souvent sans déclencher d'alerte, car le serveur CI/CD est un émetteur de connexion autorisé dans les règles firewall.

L'angle mort organisationnel. Dans beaucoup d'organisations, les serveurs CI/CD sont gérés par les équipes DevOps ou plateforme, pas par la sécurité. Ils ne figurent pas dans le périmètre des scans de vulnérabilités réguliers. Ils ne sont pas supervisés par le SIEM. Leurs logs d'accès ne sont pas conservés 12 mois comme les logs des serveurs de production. Cette fragmentation organisationnelle crée exactement le type de zone grise que les APT cherchent à exploiter : un système à hautes permissions, peu surveillé, rarement patché en urgence, avec des droits de connexion vers la production.

L'historique d'exploitation de TeamCity : un cas d'école répété

TeamCity est devenu malgré lui le cas d'école des vulnérabilités CI/CD critiques. Le pattern se répète à un rythme inquiétant, sur le même produit, avec les mêmes conséquences.

Octobre 2023 — CVE-2023-42793. Bypass d'authentification CVSS 9.8 permettant à tout attaquant réseau d'accéder à l'interface d'administration sans identifiant. Les détails techniques ont circulé avant la communication officielle de JetBrains. Des acteurs APT nord-coréens (groupe Lazarus) et russes (Fancy Bear / APT28) ont exploité la faille dans les 48 heures. La CISA et le FBI ont publié un avis conjoint en décembre 2023 documentant des compromissions de chaînes d'approvisionnement logicielles, avec des victimes dans les secteurs défense, technologie et finance.

Mars 2024 — CVE-2024-27198 et CVE-2024-27199. Double bypass d'authentification (CVSS 9.8 et 7.3) permettant l'accès à l'API REST et au système de fichiers du serveur TeamCity sans authentification préalable. Rapid7 publie les détails techniques complets le 4 mars 2024. Le 5 mars au matin, des milliers de serveurs sont déjà en cours de compromission automatisée via des scanners publics. Des groupes ransomware (BianLian, Black Basta) utilisent ces accès initiaux pour déployer des cryptolockers, et des groupes d'espionnage pour installer des implants persistants dans les pipelines de build de leurs victimes.

Juillet 2026 — CVE-2026-63077. Désérialisation non authentifiée CVSS 9.8 dans le protocole de polling des agents. Même niveau de criticité, même surface d'attaque, même réponse requise en urgence. L'exploitation active n'est pas encore confirmée au 29 juillet 2026, mais le précédent suggère une fenêtre de 24 à 48 heures maximum après la publication d'un Proof of Concept.

Ce pattern se répète parce que les organisations ne traitent pas les serveurs CI/CD avec le même niveau de rigueur que leurs serveurs de production. Un serveur web exposé reçoit des patchs de sécurité en urgence, avec un processus d'escalade clair et des SLA définis. Un serveur TeamCity interne — même exposé sur Internet — peut rester sans patch pendant des semaines parce qu'il est perçu comme un outil de développement, pas comme une surface d'attaque externe critique. L'historique d'exploitation de TeamCity devrait avoir mis fin à cette perception depuis 2023.

Ce que j'observe en mission : les angles morts les plus courants

En intervention chez mes clients, je rencontre systématiquement les mêmes configurations problématiques autour des environnements CI/CD. Je les documente ici sans nommer de clients, mais les patterns sont suffisamment répandus pour être utiles à titre général.

Les runners sans segmentation vers la production. Pour que les pipelines de déploiement fonctionnent, les runners (GitHub Actions, GitLab CI, TeamCity agents) ont besoin d'accès aux environnements cibles. Dans beaucoup de configurations, ces runners sont placés dans une zone "interne" mais ont des règles de pare-feu qui leur permettent d'atteindre directement les serveurs de production sur des ports d'administration (SSH 22, Kubernetes API 6443, API cloud en accès direct). Un attaquant qui compromet un runner a une voie directe vers la production sans avoir à franchir d'autre périmètre. La solution — des runners ségrégués par environnement, avec des connexions pull depuis un vault centralisé — n'est pas complexe mais nécessite une refonte de l'architecture de déploiement que peu d'organisations font de manière proactive.

Les secrets en clair dans les fichiers de pipeline. GitHub Actions, GitLab CI et TeamCity permettent tous de stocker des secrets de manière sécurisée. Mais dans la pratique, ces mécanismes sont mal compris et souvent contournés : les développeurs hardcodent les credentials dans les fichiers YAML de pipeline, dans les scripts de build, ou les passent en variables d'environnement non protégées qui apparaissent en clair dans les logs de build. Un audit de 50 dépôts clients réalisé en 2025 a identifié des credentials en clair dans des fichiers CI dans 62 % des cas. Ces credentials sont lisibles par quiconque accède au serveur CI/CD — légitime ou malveillant.

L'absence de supervision du serveur CI/CD lui-même. Les serveurs TeamCity et Jenkins tournent souvent sans agent EDR, sans surveillance des processus fils, sans alerting sur les connexions sortantes. Si un attaquant exploite CVE-2026-63077 et spawne un shell, la détection repose uniquement sur la corrélation des logs réseau — quand ces logs existent et sont conservés avec une durée suffisante. Installer un agent EDR sur le serveur CI/CD, l'inclure dans le périmètre SIEM et alerter sur tout spawn de processus inattendu depuis le processus TeamCity ou Jenkins sont des mesures basiques mais rarement en place dans les environnements que je rencontre.

Les artefacts non vérifiables. La reproductibilité des builds (reproductible builds) est la seule garantie technique qu'un binaire produit correspond exactement au code source de référence. Sans elle, il est impossible de détecter une injection au niveau du pipeline a posteriori. Debian, NixOS, Firefox et Chromium ont mis en place des builds reproductibles avec succès à grande échelle. Dans les entreprises, c'est encore extrêmement rare. Pour les logiciels distribués à des tiers ou déployés sur des infrastructures critiques, cette exigence devient néanmoins pertinente dans le contexte des obligations NIS2 sur la sécurité de la chaîne d'approvisionnement.

La gestion des droits des pipelines. Les pipelines de build ont besoin de droits pour fonctionner, mais ces droits sont souvent surfacés : accès en écriture à l'ensemble des branches d'un dépôt, credentials d'un compte de service avec des droits administrateur en production, tokens API sans restriction de scope. Appliquer le principe du moindre privilège aux pipelines — un token de déploiement qui ne peut écrire que dans un environnement spécifique, un compte de service qui ne peut pas lire les secrets de production — réduit considérablement l'impact d'une compromission du pipeline.

La réglementation arrive — préparez-vous maintenant

La directive NIS2, transposée en droit français par la loi de transposition de 2024, impose aux entités essentielles et entités importantes une gestion rigoureuse de la sécurité de leur chaîne d'approvisionnement logicielle. L'article 21 de NIS2 cite explicitement la sécurité des processus de développement et des chaînes d'approvisionnement comme mesures techniques et organisationnelles minimales.

L'ENISA, dans ses guidelines sur la sécurité de la supply chain logicielle publiées en 2024, liste la sécurisation des environnements de build et de CI/CD parmi les 10 contrôles prioritaires pour les entités soumises à NIS2. Concrètement, lors d'un audit de conformité NIS2, un serveur CI/CD exposé sur Internet sans patch récent, sans monitoring et sans contrôle des secrets sera un finding de première priorité pouvant conduire à une non-conformité formelle.

Aux États-Unis, le NIST SP 800-218 (Secure Software Development Framework) et l'Executive Order 14028 imposent aux fournisseurs de logiciels travaillant avec le gouvernement fédéral de documenter et sécuriser leurs pipelines CI/CD, avec des attestations de conformité. Le marché européen de la défense commence à aligner ses exigences de qualification sur des critères similaires, notamment pour les contrats relevant du règlement EUCS (European Union Cybersecurity Scheme).

La fenêtre pour traiter ce sujet de manière proactive se réduit. Attendre un incident pour justifier l'investissement dans la sécurité CI/CD, c'est choisir d'apprendre à ses dépens avec les coûts associés : remédiation forensique (souvent entre 200 000 et 800 000 euros pour un incident CI/CD majeur selon les données Mandiant 2025), reconstruction complète des pipelines, renouvellement de tous les secrets, notification réglementaire si des données clients sont accessibles depuis les pipelines, et impact réputationnel si vous distribuez des logiciels à des tiers.

5 actions concrètes à lancer cette semaine

Sans rentrer dans une roadmap pluriannuelle, voici ce qui peut être fait rapidement avec un impact immédiat sur le risque.

1. Patcher CVE-2026-63077 maintenant. Si vous tournez sur TeamCity On-Premises, c'est l'urgence absolue du jour. Versions cibles : 2025.11.7 ou 2026.1.3. Si vous ne pouvez pas patcher immédiatement, installez le plugin de sécurité JetBrains et isolez le serveur derrière un VPN dans l'attente de la fenêtre de maintenance.

2. Inventorier tous vos serveurs CI/CD exposés sur Internet. Lancez un scan de votre périmètre externe avec Shodan, Censys, ou votre outil de gestion de surface d'attaque pour identifier les instances CI/CD visibles depuis l'extérieur. Tout ce qui n'a pas besoin d'être exposé doit passer derrière un VPN ou être restreint par liste blanche d'IP dans les 24 heures.

3. Auditer les secrets stockés dans vos pipelines. Cherchez dans vos fichiers YAML CI, vos scripts de build et vos variables d'environnement de pipeline tout ce qui ressemble à une clé d'API, un mot de passe ou un token. Migrez-les vers un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) avec rotation automatique. C'est un chantier de quelques jours pour un bénéfice durable.

4. Installer un EDR sur vos serveurs CI/CD. Tout serveur qui a accès à vos environnements de production et à vos secrets doit être supervisé par un agent de détection. Configurez des alertes sur tout spawn de processus shell (bash, sh, cmd, powershell) depuis le processus principal de votre serveur CI/CD — c'est le signal d'exploitation le plus fiable pour une RCE de type CVE-2026-63077.

5. Tester votre plan de réponse. Si votre serveur CI/CD est compromis demain matin, avez-vous une procédure documentée pour identifier les builds potentiellement compromis, révoquer tous les secrets, reconstruire le pipeline depuis un état contrôlé et notifier les équipes concernées ? Si la réponse est non, c'est le chantier qui mérite le plus d'attention cette semaine.

Jenkins, GitLab CI, GitHub Actions : le risque dépasse TeamCity

Se focaliser sur TeamCity serait une erreur d'analyse. Jenkins reste le serveur CI/CD le plus déployé au monde avec plusieurs centaines de milliers d'instances recensées, et son écosystème de plus de 1 800 plugins tiers constitue une surface d'attaque considérable — beaucoup ne reçoivent plus de correctifs depuis des années. En 2025, une chaîne d'exploitation combinant CVE-2024-23897 (lecture de fichiers arbitraire via la CLI Jenkins) et un plugin d'authentification mal configuré a permis à un groupe affilié à Lazarus d'exfiltrer des clés de signature de code chez un éditeur de logiciels embarqués sud-coréen.

GitLab CI et GitHub Actions ne sont pas épargnés, mais le vecteur change de nature : au lieu de RCE sur le serveur lui-même, les attaquants exploitent la confiance accordée aux workflows. Les attaques par pipeline poisoning — injection de code malveillant via une pull request qui déclenche un workflow avec des permissions élevées, ou via une dépendance de build compromise (typosquatting npm/PyPI, GitHub Actions tierces non épinglées par hash) — ont représenté selon les données OX Security près de 35 % des incidents supply chain observés en 2025. Le cas emblématique reste tj-actions/changed-files en mars 2025 : une action GitHub largement réutilisée (plus de 23 000 dépôts) a été compromise pour exfiltrer des secrets CI directement dans les logs de build, rendus publics.

Le point commun de tous ces cas : la confiance implicite accordée à un composant tiers dans la chaîne de build, qu'il s'agisse d'un plugin, d'une action réutilisable ou d'une image Docker de base. Un audit de vos pipelines doit désormais inclure un inventaire exhaustif de ces dépendances externes, au même titre qu'un SBOM pour votre code applicatif.

Boîte à outils : détecter et durcir un pipeline CI/CD

Au-delà des correctifs et de l'isolation réseau déjà évoqués, plusieurs briques techniques permettent de réduire concrètement la surface d'attaque et d'améliorer la détection :

• Signature et provenance des artefacts — le framework SLSA (Supply-chain Levels for Software Artifacts, projet OpenSSF) définit quatre niveaux de maturité pour garantir qu'un binaire produit correspond bien au code source revu. Combiné à Sigstore/cosign pour signer et vérifier chaque artefact de build sans gestion de clés PKI traditionnelle, il devient possible de bloquer le déploiement de tout binaire non signé par le pipeline légitime.
• Scan de secrets en continu — des outils comme Gitleaks, TruffleHog ou GitGuardian, intégrés en pré-commit et en étape de pipeline, détectent les clés API, tokens et identifiants codés en dur avant qu'ils n'atteignent un dépôt ou ne fuient dans des logs de build publics.
• Tokens de courte durée via OIDC — remplacer les secrets statiques stockés dans le CI (clés cloud AWS/Azure/GCP permanentes) par de l'authentification fédérée OpenID Connect générant des credentials valides quelques minutes, le temps du job. GitHub Actions, GitLab CI et CircleCI supportent nativement ce mécanisme depuis 2023-2024 ; son adoption reste pourtant minoritaire dans les organisations que j'audite.
• Politiques as-code — Open Policy Agent (OPA) et Conftest permettent d'imposer des règles obligatoires au niveau du pipeline (interdiction des images Docker non scannées, obligation de revue à deux personnes sur les workflows modifiant les permissions, blocage des actions GitHub non épinglées par hash de commit plutôt que par tag).
• Détection comportementale — un EDR classique ne couvre pas un serveur CI/CD headless. Des solutions spécialisées (Cycode, Legit Security, Aikido) surveillent spécifiquement les patterns d'abus propres au CI/CD : modification de workflow hors heures ouvrées, ajout d'une étape de build inhabituelle, appel réseau sortant depuis un runner vers un domaine non catalogué.

Aucun de ces outils n'est une solution miracle isolée. Leur valeur vient de la combinaison : provenance vérifiable + secrets éphémères + politique automatisée + détection comportementale forment une défense en profondeur adaptée à un composant qui, par construction, a accès à tout ce que vous déployez.

Questions fréquentes

Qu'est-ce que CI/CD sécurité APT supply chain et pourquoi est-ce important ?

La réponse dépend du contexte organisationnel, mais les principes fondamentaux restent constants : évaluation du périmètre, identification des actifs critiques et priorisation par risque réel plutôt que par vulnérabilité isolée.

Comment mettre en oeuvre les bonnes pratiques liées à CI/CD sécurité APT supply chain ?

Une approche structurée et documentée est clé. Les outils et méthodologies évoluent rapidement — rester informé des ressources ANSSI, NIST et MITRE ATT&CK est indispensable pour adapter les recommandations génériques à chaque contexte.

Quelles ressources pour approfondir CI/CD sécurité APT supply chain ?

Les ressources officielles (ANSSI, CISA, CERT-FR) constituent le point de départ. Complétées par des retours d'expérience terrain, elles permettent d'adapter les recommandations aux réalités opérationnelles de chaque organisation.

Conclusion

La supply chain logicielle est le champ de bataille de la décennie. SolarWinds l'a démontré en 2020. 3CX l'a confirmé en 2023. Les vulnérabilités répétées de TeamCity le rappellent chaque année depuis 2023. L'objectif des attaquants n'est plus de forcer les portes — c'est de s'inviter par la porte de service que personne ne surveille : votre pipeline de build.

Sécuriser vos pipelines CI/CD n'est pas un projet de sécurité parmi d'autres. C'est une condition préalable à la sécurité de tout ce que vous déployez. Et contrairement à beaucoup de chantiers de sécurité, les gains les plus importants s'obtiennent avec des mesures de bon sens : patcher, isoler, monitorer, gérer les secrets proprement. Commencez par là. Cette semaine, pas au prochain trimestre.