Trivy et TeamPCP : failles critiques dans la chaîne logistique
Analyse technique
Mécanique du Tag Poisoning et déroulé probable
Le Tag Poisoning désigne la substitution ou la modification malveillante de tags d'artefacts - images conteneurs, versions de paquets ou releases - afin que des processus automatisés téléchargent et déploient des versions compromises. L'attaque joue sur la confiance que les équipes portent aux tags dits stables, comme "latest" ou "v1.2", sans toujours vérifier l'origine réelle des artefacts.
La campagne récemment attribuée à TeamPCP illustre cette mécanique en exploitant un vecteur concret : la compromission d'un scanner d'images largement déployé, Trivy. Un attaquant qui parvient à injecter du code dans un binaire de scan ou à retagger une release peut contaminer l'ensemble des pipelines qui s'appuient sur cet outil¹.
Concrètement, l'enchaînement observé suit ces étapes : compromission d'un outil distribué via des releases publiques ; altération des métadonnées et retagging d'images ; publication de conteneurs contenant des backdoors ; exfiltration de secrets présents dans l'environnement CI/CD ; et installation de mécanismes de persistance déclenchés uniquement sous certaines conditions pour échapper à la détection. La logique du déclenchement conditionnel complique la découverte, car le payload peut rester inactif jusqu'à la présence d'un repository ou d'une configuration précise.
Vecteurs techniques observés et risques associés
- Registres publics et privés mal isolés. Une mauvaise résolution des registres permet à une image retaggée dans un registre prioritaire de remplacer une image interne.
- Permissions excessives sur les tokens CI. Des scopes 'write' ou 'admin' facilitent le retagging d'artefacts et la publication d'images compromises.
- Absence de signatures d'artefacts. Sans signature (cosign, sigstore), l'intégrité se réduit au nom et au tag, faciles à usurper.
- Dépendances transversales dans les scanners. Les scanners intègrent souvent des plugins ou librairies qui échappent aux contrôles habituels et peuvent être manipulés pour délivrer des faux positifs ou injecter du code.
Exemples concrets et preuves de concept
Remplacer une image de base est trivial si les priorités de résolution de registre favorisent une source externe. Un pipeline qui récupère "company-base:stable" sans validation d'empreinte peut se retrouver à exécuter une image contenant une backdoor. Autre scénario : des agents CI téléchargent un binaire signé sur un compte GitHub compromis. Si ce téléchargement se fait sans vérification de l'empreinte, le pipeline exécute du code malveillant qui va scanner l'environnement à la recherche de tokens à exfiltrer.
Les logs et artefacts envoyés vers des stockages cloud constituent une autre fuite classique. Un binaire compromis peut scrapper des variables d'environnement, des fichiers temporaires ou des traces de commandes et les exfiltrer vers un endpoint contrôlé, sans déclencher d'alerte immédiate.
Défauts de conception système mis en évidence
- Confiance implicite dans les tags et dans les releases publiques.
- Téléchargement à la volée d'outils open-source sans vérification systématique des empreintes ou des signatures.
- Pipelines qui autorisent la publication ou le retagging d'images sans principe 'deny by default' et sans séparation des privilèges.
Impacts business
Risques immédiats pour l'entreprise
- Déploiement de code non approuvé, incluant backdoors ou crypto-miners pouvant persister dans l'infrastructure.
- Exfiltration de données et de secrets : l'accès aux tokens CI/CD et aux identifiants cloud peut conduire à des vols d'actifs ou à des attaques de type ransomware.
- Interruption de service suite à des payloads destructeurs ou à des modifications malveillantes des workflows.
Coûts directs et indirects
La réponse à incident et les investigations forensiques mobilisent des ressources internes et externes, parfois pendant plusieurs semaines. Les coûts comprennent la remise en service, la revalidation des chaînes de build, les audits et, le cas échéant, les notifications réglementaires. Des études sectorielles montrent que le coût moyen d'une brèche peut atteindre plusieurs millions de dollars, en fonction de l'ampleur et du secteur².
La réputation subit un impact durable : perte de confiance des clients, effets sur le cours de l'action, coûts juridiques et sanctions réglementaires en cas d'exfiltration de données personnelles. Ces conséquences augmentent drastiquement la facture finale.
Exposition particulière des fournisseurs cloud et des environnements CI/CD
Les systèmes qui fournissent un accès programmatique à la production, comme les CD, sont des cibles à haut risque. Si un scanner d'images est compromis, la contamination se propage rapidement via tous les pipelines qui lui font confiance. Les runners mutualisés élargissent le blast radius : un runner partagé compromis peut être utilisé pour attaquer plusieurs projets ou équipes.
Recommandations
Contrôles immédiats (24-72 heures)
- Révoquer et régénérer tous les tokens CI avec des scopes larges ; appliquer le principe du moindre privilège.
- Bloquer et isoler les versions de binaires ou d'images téléchargées automatiquement si elles ne sont pas signées ; vérifier les empreintes lorsque c'est possible.
- Auditer les registres de paquets et les tags récemment modifiés ; mettre en quarantaine les artefacts suspects.
- Restreindre les privilèges des runners CI/CD et isoler les builds sensibles.
Mesures opérationnelles (2-8 semaines)
- Déployer la signature d'artefacts via cosign/sigstore et rendre la vérification obligatoire au moment du déploiement.
- Adopter SLSA pour améliorer la traçabilité des builds et la provenance des artefacts³.
- Produire un SBOM pour chaque build afin de tracer les composants tiers.
- Renforcer la gestion des secrets : utiliser des vaults, éviter les secrets en clair et activer le scanning des secrets.
- Segmenter les registres : forcer la résolution vers des registres internes signés ou valider l'origine avec des whitelists.
Mesures techniques avancées (3-6 mois)
- Appliquer des politiques d'admission sur Kubernetes pour refuser des images non signées.
- Intégrer de la protection des workloads cloud et des solutions EDR pour détecter des comportements anormaux après déploiement.
- Automatiser la rotation des clés et mettre en place un audit continu avec alertes sur tout retagging massif ou publication inhabituelle.
- Organiser des exercices de red team centrés sur la chaîne logistique pour valider les contrôles.
Gouvernance et formation
- Mettre en place des revues formelles des voies de build et des processus de publication d'artefacts ; nommer des responsables de la sécurité de la chaîne logistique.
- Former les équipes DevOps/DevSecOps aux risques liés à la supply chain : vérification d'empreintes, publication sécurisée et bonnes pratiques de hardening.
Renforcer l'authenticité et l'intégrité des artefacts n'est plus une option. La campagne TeamPCP montre que la combinaison d'artefacts largement utilisés, d'autorisations laxistes et d'absence de signature crée une surface d'attaque critique¹. Si les contrôles ne sont pas appliqués rapidement, la probabilité d'une nouvelle compromission reste élevée.
