TeamPCP : quand vos outils de sécurité deviennent l'arme de l'attaquant

En mars 2026, des milliers d'équipes DevSecOps ont fait face à un scénario qu'elles n'avaient pas envisagé dans leurs modèles de menace : leurs outils de sécurité s'étaient transformés en vecteurs d'exfiltration. Trivy — le scanner de vulnérabilités le plus téléchargé de l'écosystème CNCF — avait été compromis. Puis Checkmarx KICS. Puis LiteLLM. Le groupe TeamPCP venait de réussir l'une des attaques supply chain les plus sophistiquées et les plus dévastatrices jamais documentées contre l'outillage DevSecOps. Ce n'est pas une histoire de zero-day exotique. C'est une histoire de confiance mal placée, de mécanismes d'intégrité ignorés, et d'angles morts systémiques laissés ouverts par commodité.

Anatomie d'une attaque en cascade : de Trivy à Checkmarx en cinq jours

Le 19 mars 2026, un commit malveillant est passé inaperçu dans le dépôt GitHub aquasecurity/trivy-action. Les attaquants — identifiés sous le nom TeamPCP par Kaspersky, Arctic Wolf et Cisco Talos — avaient obtenu des tokens d'accès leur permettant de réécrire les tags Git du projet. Ils ont procédé avec une méthode chirurgicale : sur 77 tags de version existants dans aquasecurity/trivy-action, 76 ont été redirigés vers un commit malveillant contenant la charge SANDCLOCK. Dans le dépôt aquasecurity/setup-trivy, la totalité des 7 tags existants ont été corrompus. CVE-2026-33634 a été assigné à cet incident, avec un score CVSS4B de 9.4.

La technique utilisée est le "tag poisoning" — réécriture de tag Git. Dans un pipeline CI/CD typique, les workflows GitHub Actions référencent des actions par leur tag de version pour des raisons de stabilité et de lisibilité. Lorsqu'un workflow spécifie uses: aquasecurity/trivy-action@v0.29.0, GitHub Actions télécharge le contenu correspondant à ce tag au moment de l'exécution. Si le tag a été réécrit pour pointer vers un commit différent — ce que Git permet nativement avec git tag -f — c'est le nouveau contenu malveillant qui s'exécute, tout en conservant l'apparence visuelle de la version légitime dans les logs du workflow.

Chaque pipeline exécutant Trivy devenait ainsi un vecteur d'exfiltration silencieux. Trivy s'exécutant avec les privilèges du runner CI — souvent élevés pour accéder aux images Docker, aux registres privés et aux fichiers de configuration — SANDCLOCK disposait d'un accès privilégié aux variables d'environnement, aux fichiers de credentials du runner et aux tokens d'accès aux services cloud. Les exfiltrations passaient complètement inaperçues dans le flux normal des requêtes HTTPS sortantes d'un pipeline CI/CD actif.

Le 23 mars 2026, TeamPCP passait à la phase suivante. En utilisant des credentials GitHub volés par SANDCLOCK lors de scans Trivy compromis dans des organisations ayant des accès aux dépôts Checkmarx, le groupe a réussi à compromettre ast-github-action et kics-github-action — les actions GitHub officielles de Checkmarx pour les scans de sécurité applicative (AST) et d'infrastructure-as-code (KICS). La compromission d'un outil de sécurité alimentait directement la compromission du suivant : une cascade parfaitement orchestrée où chaque victime devenait un vecteur d'attaque contre la suivante.

Le 24 mars 2026, TeamPCP publiait directement sur PyPI des versions malveillantes de LiteLLM (versions 1.82.7 et 1.82.8), le proxy LLM open-source très utilisé dans les pipelines d'automatisation IA. Cette fois, la compromission ne passait pas par GitHub Actions mais par l'accès direct au compte PyPI du mainteneur — obtenu via des tokens PyPI volés lors des phases précédentes de la campagne. En cinq jours, TeamPCP avait transformé trois outils critiques de l'écosystème DevSecOps en pipelines d'exfiltration actifs. Selon les analyses d'Arctic Wolf et de l'unité Unit 42 de Palo Alto Networks, au moins 1 000 environnements SaaS enterprise ont été impactés par cette campagne.

SANDCLOCK : le stealer conçu spécifiquement pour l'environnement CI/CD

SANDCLOCK n'est pas un stealer généraliste recyclé pour l'occasion. Il a été développé avec une connaissance précise et approfondie des secrets que les environnements de runners CI/CD hébergent typiquement — une spécialisation qui témoigne d'une maturité opérationnelle significative de la part de TeamPCP.

La première catégorie de secrets ciblés est les tokens cloud. SANDCLOCK recherche activement les variables d'environnement AWS (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN), les credentials GCP (GOOGLE_APPLICATION_CREDENTIALS, GCLOUD_SERVICE_KEY), et les tokens Azure (AZURE_CLIENT_SECRET, AZURE_CREDENTIALS, AZURE_TENANT_ID). Dans un runner CI/CD, ces credentials sont souvent injectés comme variables d'environnement au moment du build pour permettre aux workflows de déployer des artefacts ou d'interagir avec des services cloud managés. Leur compromission donne aux attaquants un accès direct à l'infrastructure cloud de la cible.

La deuxième catégorie est les tokens GitHub et les publishing tokens de registres de packages. Le GITHUB_TOKEN — automatiquement injecté par GitHub Actions dans chaque workflow — donne accès en écriture au dépôt courant et, dans certaines configurations, à d'autres dépôts de la même organisation. Les tokens npm et PyPI permettent de publier des packages. C'est exactement via ce mécanisme que TeamPCP a pu se propager de Trivy vers Checkmarx : en exfiltrant les GITHUB_TOKEN de runners appartenant à des organisations ayant des accès aux dépôts Checkmarx, le groupe a obtenu les credentials nécessaires à la phase suivante sans avoir besoin d'aucune vulnérabilité supplémentaire.

La troisième catégorie couvre les clés SSH stockées dans les répertoires home du runner, les credentials de registres Docker (fichier ~/.docker/config.json), les clés de chiffrement et les clés API de services tiers — Slack, Jira, Datadog, PagerDuty — tous couramment présents dans les pipelines CI/CD modernes. L'analyse technique de Datadog Security Labs révèle que SANDCLOCK dispose également d'un mécanisme de persistance sur les runners auto-hébergés réutilisés entre les builds : le stealer installe une backdoor SSH persistante permettant un accès ultérieur même après nettoyage des workspaces.

L'exfiltration se fait via des requêtes HTTPS sortantes vers des serveurs de command and control utilisant des noms de domaine camouflés pour ressembler à des CDN ou services légitimes. Cette technique de domain camouflage rend la détection par filtrage DNS difficile dans des environnements où des centaines de domaines légitimes sont contactés lors de chaque build CI/CD actif.

Pourquoi les outils de sécurité sont la cible idéale pour une attaque supply chain

L'aspect le plus troublant de l'attaque TeamPCP n'est pas sa sophistication technique — des attaques supply chain sur des packages npm ou PyPI ont déjà été documentées à de nombreuses reprises. C'est le choix délibéré et stratégique de cibler des outils de sécurité. Ce n'est pas un accident. C'est une décision calculée qui exploite plusieurs caractéristiques structurelles de l'écosystème DevSecOps.

Premier facteur : les outils de sécurité bénéficient d'un niveau de confiance implicite plus élevé que les outils généraux. Une organisation peut refuser d'exécuter du code tiers non-vérifié dans son pipeline de production — mais elle exécutera systématiquement un scanner de sécurité avec des privilèges élevés, par nécessité technique. Trivy a besoin d'accéder aux images Docker et aux fichiers de configuration pour les scanner. Checkmarx KICS a besoin de lire l'ensemble du code d'infrastructure. Ces accès sont légitimes et nécessaires — mais ils créent une surface d'exfiltration maximale pour un attaquant ayant compromis l'outil.

Deuxième facteur : les outils de sécurité sont eux-mêmes rarement dans le périmètre de surveillance. On configure des alertes pour les applications de production. On surveille le trafic réseau des serveurs exposés. On audite les accès aux bases de données. Mais qui surveille le comportement réseau d'un scanner de vulnérabilités s'exécutant dans un workflow GitHub Actions lors d'un build nocturne ? La réponse honnête, dans la grande majorité des organisations : personne. Les outils de sécurité sont des borgnes qui surveillent les autres sans être surveillés eux-mêmes.

Troisième facteur : la chaîne de confiance repose sur la réputation. Dans l'écosystème open-source CI/CD, la confiance est construite sur la réputation du projet et de son mainteneur — une réputation qui peut être exploitée précisément parce qu'elle est établie sur des années. Trivy est un projet de la Cloud Native Computing Foundation (CNCF). Checkmarx est un éditeur de sécurité coté avec des milliers de clients enterprise. LiteLLM est l'un des projets AI open-source les plus étoilés sur GitHub. C'est cette réputation accumulée que TeamPCP a monétisée : des années de confiance construite par des équipes légitimes, retournée contre leurs utilisateurs en quelques commits soigneusement planifiés.

La compromission de la chaîne de confiance : une vulnérabilité architecturale fondamentale

L'attaque TeamPCP révèle une vulnérabilité architecturale fondamentale de l'écosystème open-source CI/CD : la chaîne de confiance repose sur des mécanismes qui n'ont pas été conçus pour résister à une compromission des tags Git ou des comptes de mainteneurs.

Lorsqu'un workflow GitHub Actions référence uses: aquasecurity/trivy-action@v0.29.0, GitHub résout ce tag sémantique en un hash de commit via le registre Git du dépôt. Si le tag est réécrit — ce que Git permet par design avec git tag -f — la résolution pointe vers le nouveau commit malveillant, tout en affichant toujours @v0.29.0 dans les logs. L'opérateur voit une version légitime, conforme à sa politique de gestion des dépendances, mais exécute en réalité du code malveillant.

La solution recommandée — épingler les actions par hash de commit immuable plutôt que par tag sémantique — existait avant l'attaque TeamPCP. L'OpenSSF (Open Source Security Foundation) la préconisait dans son Scorecards framework depuis 2021. En pratique, elle est rarement appliquée. Les hashs de commit sont des chaînes hexadécimales illisibles, difficiles à maintenir lors des mises à jour, et la pression permanente du cycle de développement fait que les équipes utilisent les tags sémantiques par commodité et par convention. La protection optimale était disponible — elle n'était pas adoptée.

GitHub a depuis déployé un mécanisme d'immutabilité des tags (Immutable Actions) pour les actions publiées dans le GitHub Marketplace après mars 2026. C'est une amélioration réelle mais partielle. Les projets hébergés directement sur GitHub sans passer par le Marketplace — la majorité des outils CI open-source — restent soumis à ce vecteur tant que les consommateurs n'adoptent pas l'épinglage par hash de commit.

Ce que les équipes DevSecOps doivent changer concrètement

TeamPCP force une révision structurelle du modèle de confiance dans les pipelines CI/CD. Voici les changements concrets, par ordre de priorité opérationnelle et d'impact défensif.

Épingler toutes les GitHub Actions par hash de commit. Remplacer uses: aquasecurity/trivy-action@v0.29.0 par uses: aquasecurity/trivy-action@[commit-sha]. C'est contraignant à maintenir manuellement, mais des outils comme Renovate Bot ou Dependabot peuvent automatiser les mises à jour de ces hashs tout en conservant la protection contre le tag poisoning. Cette mesure seule aurait rendu l'attaque TeamPCP inopérante contre les organisations l'ayant appliquée.

Mettre en place un filtrage egress depuis les runners CI/CD. Un scanner de vulnérabilités n'a aucune raison légitime de contacter un domaine inconnu ou non-répertorié. La mise en place d'une liste d'allowance des domaines autorisés pour les requêtes HTTPS sortantes depuis les runners constitue une couche de détection et de blocage efficace contre les stealers qui exfiltrent vers des C2 inconnus. Ce filtrage egress est rarement présent dans les pipelines cloud-hosted — c'est une lacune structurelle à corriger en priorité.

Appliquer le principe de moindre privilège aux workflows CI/CD. Un workflow de scan de sécurité ne devrait jamais avoir accès aux credentials de déploiement en production. La séparation stricte des workflows — scan dans un job isolé sans accès cloud de production, déploiement dans un job séparé avec credentials limités au strict nécessaire — réduit drastiquement la surface d'exfiltration si un outil de scan est compromis. Le modèle de permissions GitHub Actions permet cette granularité fine : utilisez-la.

Surveiller le comportement des outils de sécurité eux-mêmes. L'eBPF (Extended Berkeley Packet Filter) permet d'instrumenter le comportement réseau et les appels système d'un processus spécifique, même dans un container. Des outils comme Falco ou Tetragon peuvent générer des alertes si un scanner de vulnérabilités effectue des connexions réseau vers des destinations inhabituelles ou des appels syscall anormaux (lecture de ~/.ssh, accès aux fichiers de configuration cloud). Surveiller les surveillants — c'est le chaînon manquant dans la plupart des architectures CI/CD actuelles.

Vérifier les hashs des packages installés, pas seulement les versions. pip install litellm==1.82.7 installe la version disponible sur PyPI au moment de l'exécution sans vérifier si cette version correspond au contenu attendu. L'utilisation de fichiers de verrouillage avec hashs SHA256 intégrés — pip-compile avec --generate-hashes, poetry.lock, npm shrinkwrap — permet de détecter une substitution de package. Si un hash SHA256 attendu avait été vérifié pour LiteLLM 1.82.7, toute installation de la version compromise aurait échoué avec une erreur d'intégrité détectable.

Les limites des mesures actuelles : une honnêteté nécessaire

Il serait intellectuellement malhonnête de présenter ces recommandations comme une solution complète au problème structurel exposé par TeamPCP. Elles réduisent significativement la surface d'attaque — mais elles ne résolvent pas le problème fondamental de la confiance dans l'écosystème open-source.

L'épinglage par hash de commit protège contre le tag poisoning, mais pas contre une compromission du compte mainteneur poussant directement un nouveau commit malveillant avec un hash inédit. Dans ce scénario, Renovate Bot proposerait une mise à jour vers le commit compromis, et une revue humaine inattentive pourrait l'approuver sans détecter la malveillance.

Le filtrage egress est efficace contre des C2 utilisant des domaines inconnus. Des attaquants suffisamment sophistiqués peuvent utiliser des domaines légitimes comme intermédiaires — GitHub Gist, services de stockage cloud, CDN publics — pour exfiltrer des données de manière indiscernable du trafic légitime. TeamPCP utilisait déjà des techniques de camouflage de domaine lors de la campagne de mars 2026.

La vérité inconfortable est que la sécurité des supply chains logicielles reste fondamentalement un problème de confiance dans un écosystème conçu pour la collaboration ouverte et non pour la vérification systématique. L'open-source a construit une infrastructure mondiale extraordinaire sur des hypothèses de bonne foi : que les mainteneurs ne seront pas compromis, que les plateformes de distribution resteront intègres, que la communauté détectera rapidement les modifications malveillantes. TeamPCP a démontré que ces hypothèses peuvent être violées de manière coordonnée et méthodique, en utilisant la réputation établie des projets comme vecteur de distribution à grande échelle.

Conclusion : la fin de la confiance implicite dans le DevSecOps

L'attaque TeamPCP contre Trivy, Checkmarx KICS et LiteLLM marque un tournant dans l'histoire des attaques supply chain logicielle. En ciblant délibérément des outils de sécurité établis et en orchestrant une cascade de compromissions où chaque outil compromis alimentait la compromission du suivant, le groupe a démontré une compréhension approfondie des angles morts collectifs des équipes DevSecOps et une capacité d'exécution opérationnelle que l'écosystème ne peut plus sous-estimer.

Pour les RSSI et les responsables DevSecOps, le message est clair : le modèle de confiance implicite dans les outils open-source de sécurité est désormais une hypothèse réfutée dans les faits. Chaque composant du pipeline CI/CD mérite le même niveau de scrutin que le code applicatif lui-même. L'épinglage par hash, le filtrage egress, la séparation des privilèges et la surveillance comportementale des outils de sécurité ne sont plus des bonnes pratiques optionnelles — ce sont des prérequis pour tout environnement dont la supply chain logicielle représente un risque métier réel.

CVE-2026-33634 ne sera pas le dernier incident de ce type. Les groupes qui ont observé le succès de TeamPCP en ont tiré des leçons. La prochaine campagne sera probablement plus ciblée, plus patiente, et plus difficile à détecter. Les organisations qui auront revu leur modèle de confiance CI/CD seront significativement mieux préparées. Celles qui n'auront pas bougé resteront des cibles de choix — avec un outillage DevSecOps qui pourrait se retourner contre elles.