Trivy et Tag Poisoning : Menaces pour la chaîne logistique CI/CD
Origines et historique
Trivy est devenu un outil de référence pour scanner des images conteneurs, des dépendances et des configurations Infrastructure as Code. La compromission récente liée à TeamPCP a montré comment une faille touchant un composant de l'écosystème Trivy a servi d'entrée pour publier des artefacts malveillants via un tag manipulé, phénomène souvent nommé "tag poisoning". Le rapport public qui décrit cette campagne pointe des vecteurs classiques : dépendances non épinglées, absence de vérification cryptographique et permissions de publication trop larges¹.
Attaquer la chaîne logistique n'est pas une nouveauté. L'incident SolarWinds illustre bien le risque : une mise à jour signée d'un fournisseur est devenue un vecteur pour compromettre des milliers d'organisations, ce qui rappelle la fragilité de la confiance implicite dans les artefacts distribués⁴. Depuis, la pression pour renforcer la gouvernance et l'attestation des artefacts a grandi. Des cadres comme SLSA proposent des niveaux de garanties sur la provenance et l'intégrité des builds, et les bonnes pratiques publiées par le NIST contribuent à formaliser cette discipline²³.
Chronologie synthétique (exemple générique d'une campagne de type Tag Poisoning)
- Phase 0 - Reconnaissance : identifier les outils et pipelines qui consomment des tags non vérifiés.
- Phase 1 - Compromission initiale : accès à un compte mainteneur, vol d'une clé d'API ou exploitation d'une vulnérabilité.
- Phase 2 - Implantation d'artefacts : publication d'une image ou d'un paquet malveillant sous un tag attendu.
- Phase 3 - Propagation via CI/CD : des pipelines automatisés récupèrent et déploient l'artefact compromis.
- Phase 4 - Exfiltration et maintien : maintien d'un accès, extraction de secrets ou pivot vers d'autres cibles.
Fonctionnement technique
Mécanique du "Tag Poisoning"
Le problème central vient de la coexistence entre des identifiants humains faciles à retenir (les tags) et l'identité immuable d'un artefact (le digest, ex : sha256:...). Un pipeline qui se contente d'un tag comme 'latest' ou 'vX' fait confiance à un nom lisible plutôt qu'à l'empreinte réelle. Si un attaquant parvient à publier sous ce même tag, il peut substituer l'artefact attendu par une version malveillante.
Faiblesses observées fréquemment :
- Utilisation de tags flottants au lieu de pinning par digest.
- Absence de vérification de signatures d'artefacts (cosign, Notary non utilisés).
- Permissions trop larges sur les comptes de publication et sur les runners CI.
- Absence d'attestations de provenance et d'empreinte de build (modèle SLSA non appliqué).
Schéma textuel d'une chaîne compromise
- Un développeur pousse un commit vers Git.
- Le pipeline CI déclenche un build et publie une image avec les tags 'v1.2' et 'latest' sur un registre.
- Une clé CI ou un mainteneur compromis permet à l'attaquant d'écraser le tag 'latest' avec une image malveillante.
- Un autre pipeline, configuré pour récupérer 'latest', déploie l'image compromise en production.
- L'attaquant active une porte dérobée et exfiltre des secrets ou déploie d'autres charges utiles.
Exigences techniques pour corriger le vecteur
- Pinning d'artefacts par digest, pas par tag. La référence immuable doit circuler dans les manifests et les déploiements.
- Vérification cryptographique systématique des signatures d'artefacts avec des outils comme cosign ou Notary (TUF/Notary v2).
- Génération et vérification d'attestations de provenance conformes aux recommandations SLSA afin d'établir qui a produit quoi et comment³.
- Segmentation et rotation stricte des secrets utilisés par les runners CI ; utiliser des mécanismes d'accès just-in-time et de least privilege.
- Journalisation complète des opérations de publication sur les registres et création d'alertes sur les réécritures de tags critiques.
Ces mesures doivent être automatisées dans les pipelines : la vérification doit être une étape blocante et non une option facultative.
Études de cas
1) Campagne TeamPCP ciblant Trivy et l'écosystème associé (récente)
Le rapport relayé par la presse spécialisée décrit comment la compromission d'un composant de l'écosystème Trivy a servi à diffuser des images manipulées via un tag compromis¹. L'attaque a exploité des chemins de confiance implicites : pipelines qui acceptent des tags flottants, absence de vérification des signatures et comptes de publication mal configurés.
Conséquences observées :
- Déploiement d'artefacts compromis en environnements préprod et prod.
- Exposition potentielle de secrets présents sur des runners CI ou injectés lors de phases de build.
- Dégradation de la confiance envers des composants open source clés, avec des impacts opérationnels pour des équipes qui doivent now revérifier et reconstruire des artefacts.
La leçon opérationnelle : corriger ces faiblesses demande des mesures techniques rapides (pinning, signatures) et des révisions de gouvernance pour limiter les droits de publication.
2) SolarWinds Orion - compromission d'une chaîne de mise à jour (précédent marquant)
L'incident SolarWinds a montré la portée d'une compromission d'un fournisseur : un loader malveillant intégré au produit Orion a été distribué via les mises à jour normales et a touché des milliers d'organisations⁴. Ce cas illustre que la confiance implicite dans les artefacts signés ou fournis par un tiers peut être exploitée si l'intégrité et la provenance ne sont pas vérifiées de bout en bout.
Les recommandations issues de cet incident incluent des contrôles renforcés sur la chaîne de build, la séparation des environnements de build et des mécanismes d'attestation robustes, en cohérence avec les bonnes pratiques du NIST².
Perspectives
Les attaques sur la chaîne logistique vont rester une priorité pour les attaquants, qui ciblent des éléments jugés stratégiques : scanners de sécurité, runners CI, registries et fournisseurs tiers. Deux tendances vont s'imposer :
- Adoption plus large des attestations et de l'immutabilité. Les pratiques SLSA gagnent du terrain pour établir une preuve de provenance et d'intégrité des builds³.
- Intégration systématique des vérifications cryptographiques dans les pipelines. Les fournisseurs CI/CD devront proposer, par défaut, des étapes de validation qui rejettent les artefacts non signés ou non épinglés.
Pour les RSSI et les DSI, la feuille de route est claire : cartographier les flux de dépendances, appliquer le pinning sur les artefacts critiques, automatiser la vérification des signatures et revoir les privilèges des comptes de publication. Le NIST fournit un cadre utile pour prioriser les contrôles de gestion du risque fournisseur et de la chaîne logistique².
Passer à l'échelle demande des outils et de l'automatisation. Les équipes DevOps doivent intégrer la vérification de provenance comme une étape standard du pipeline. Le suivi des logs et des modifications de tags, couplé à des revues régulières des droits, réduit substantiellement la fenêtre d'exposition.
La compromission autour de Trivy représente un signal fort pour les organisations qui s'appuient sur des composants open source. Renforcer la gouvernance, adopter des attestations de build et limiter les droits des comptes automated sont des mesures concrètes qui réduisent le risque de substitution d'artefacts.
