TeamPCP Vole des Identifiants CI via les GitHub Actions
Les faits
Qui - Une campagne de compromission a été attribuée au groupe TeamPCP, déjà associé à des attaques contre des composants de la chaîne d'approvisionnement logicielle. La première mention publique de cet incident remonte à mars 2026¹.
Quoi - Deux workflows GitHub Actions maintenus par Checkmarx ont été ciblés : checkmarx/ast-github-action et checkmarx/kics-github-action². Des identifiants CI volés ont permis aux attaquants d'exécuter des workflows disposant de permissions suffisantes pour récupérer des secrets et altérer des artefacts.
Quand - Les attaques se sont déroulées avant la divulgation publique de mars 2026, ce qui suggère une opération planifiée et active sur une période prolongée¹.
Où - Les compromissions ont eu lieu dans des dépôts publics et sur des workflows GitHub. Comme ces actions sont distribuées via la Marketplace GitHub, la surface d'impact s'étend potentiellement à de nombreux projets tiers qui importent ces actions².
Comment - TeamPCP a exploité des jetons et secrets présents dans des environnements CI, notamment des GITHUB_TOKEN et des secrets intégrés aux runners. Avec des identifiants valides, les attaquants ont démarré des runs automatisés, injecté des étapes d'exfiltration et redirigé des étapes pour pointer vers des artefacts qu'ils contrôlaient. L'utilisation d'identifiants légitimes a permis de contourner plusieurs contrôles de sécurité communs¹².
Preuves techniques observées
- Des runs de workflows initiés sans auteur humain connu, avec des patterns d'exécution atypiques dans les logs indiquant des scripts de collecte d'environnement et des transferts de données vers des destinations externes inconnues.
- Modifications opportunistes des fichiers de workflow pour ajouter des étapes qui extraient des secrets ou redirigent des étapes vers des artefacts contrôlés par les attaquants².
- Utilisation de jetons et secrets trouvés dans les configurations des projets, compatible avec une phase préalable de collecte d'identifiants ou d'accès lateral.
Contexte
TeamPCP et les attaques CI/CD - TeamPCP est connu pour cibler des pipelines CI/CD et des environnements cloud afin de voler des identifiants CI et des clés d'API. Leur précédent compromis de l'outil Trivy avait montré la capacité du groupe à toucher la chaîne d'approvisionnement et à affecter des dépendances multiples¹.
Pourquoi les actions GitHub sont une cible crédible - Une action compromise peut être importée dans des milliers de dépôts. La distribution par la Marketplace, l'utilisation de références non verrouillées et des permissions excessives sur GITHUB_TOKEN créent un vecteur d'attaque puissant.
Aspects techniques récurrents observés dans des incidents similaires :
- Jetons aux permissions excessives : des GITHUB_TOKEN configurés par défaut avec des droits d'écriture quand seule la lecture est nécessaire.
- Manque d'isolation des runners auto-hébergés, permettant des accès latéraux vers d'autres ressources internes.
- Références dynamiques aux actions (branches, tags flottants) facilitant l'injection de versions malveillantes.
Risque pour les utilisateurs de Checkmarx - Les actions Checkmarx sont utilisées pour des analyses de sécurité et pour automatiser des scans dans des pipelines. Leur compromission peut exposer des secrets, altérer des artefacts de build et éroder la confiance envers les outils d'analyse automatisée².
Réactions et conséquences
Réponses publiques et mainteneurs - Après la détection, les versions compromises des actions ont été révoquées et des avis de sécurité publiés par les mainteneurs concernés². Les bonnes pratiques immédiates recommandées incluent la rotation des secrets et la restriction des permissions accordées aux workflows.
Impacts opérationnels typiques pour les organisations :
- Exposition possible de secrets stockés dans des dépôts, comme des clés cloud ou des tokens de déploiement.
- Risque de livraison d'artefacts altérés si des builders ou des workflows de build ont été compromis.
- Effort interne significatif pour identifier les runs affectés, auditer les runners, révoquer et régénérer des clés, et corriger les workflows.
Conséquences réglementaires - Si des données personnelles sont impliquées, des obligations de notification et des sanctions prévues par le RGPD peuvent s'appliquer, en particulier si la gestion des identifiants a été négligée.
Mesures immédiates observées dans la réponse
- Rotation systématique des secrets exposés et révocation des tokens suspects.
- Blocage et retrait des versions compromises des actions et communication d'alertes aux utilisateurs concernés².
- Audit des logs d'exécution pour identifier mouvements latéraux et exfiltrations.
- Recommandation de réduire les permissions du GITHUB_TOKEN par défaut et d'adopter des mécanismes d'authentification éphémère comme OIDC pour les déploiements cloud³.
Recommandations pratiques
Mesures techniques prioritaires :
- Restreindre explicitement les permissions du GITHUB_TOKEN aux scopes strictement nécessaires. Privilégier 'read' quand l'écriture n'est pas indispensable³.
- Utiliser OIDC pour obtenir des jetons temporaires lors des déploiements vers des fournisseurs cloud afin d'éviter le stockage persistant de secrets dans les dépôts³.
- Verrouiller les références d'actions avec des SHA immuables pour éviter l'introduction silencieuse de nouvelles versions malveillantes.
- Mettre en place des contrôles d'approbation pour les actions tierces au niveau de l'organisation et limiter les sources d'actions autorisées.
- Scanner automatiquement les fichiers .github/workflows et générer des alertes sur toute modification ajoutant des URLs externes non autorisées ou des étapes inconnues.
- Isoler les runners auto-hébergés : exécuter les jobs dans des environnements éphémères et minimiser leurs droits réseau et système.
Bonnes pratiques organisationnelles :
- Tenir un inventaire des workflows et actions utilisées, avec des propriétaires identifiés et des processus de revue réguliers.
- Mettre en place des exercices de simulation d'incident spécifiques à la chaîne CI/CD pour tester détection, confinement et rétablissement.
- Appliquer la règle du moindre privilège aux comptes de service et automatiser la révocation des accès compromis.
Détection et chasse aux menaces :
- Surveiller les logs pour repérer des dispatchs sans auteur humain, des runs à des heures inhabituelles ou des transferts de données vers des domaines externes inconnus.
- Vérifier la liste des secrets accessibles aux jobs et auditer leur usage vers des endpoints externes.
- Comparer l'intégrité des artefacts produits par des runs suspects avec des builds antérieurs pour détecter toute altération.
Plan d'action de réponse recommandé :
- Identifier et isoler les runs et runners compromis.
- Révoquer les tokens suspects et procéder à la rotation des secrets critiques.
- Communiquer de façon transparente en interne et, si nécessaire, auprès des clients tout en respectant les obligations réglementaires.
- Corriger les workflows en verrouillant les références d'actions et en réduisant les permissions.
- Lancer une analyse forensique complète pour comprendre la chaîne d'impact et renforcer la posture CI/CD.
La sécurisation durable de la chaîne CI/CD exige des investissements techniques et organisationnels. Les scanners seuls ne suffisent pas si des identifiants légitimes sont compromis ou si des runners non sécurisés sont exploités. Les équipes qui maintiennent des actions publiquement distribuées doivent renforcer la gestion des clés, effectuer des audits réguliers des dépendances et coordonner avec la communauté pour tracer et bloquer la réutilisation d'actions compromises².
Gardez en tête que la réduction des privilèges et la vigilance constante sur la gestion des identifiants CI constituent les protections les plus efficaces contre ce type d'attaque³.
