Trivy Security Scanner GitHub Actions Ciblé, 75 Tags Détournés

Les faits

Qui - Il s'agit de Trivy, le scanner de vulnérabilités développé par Aqua Security, et plus précisément des actions GitHub "aquasecurity/trivy-action" et "aquasecurity/setup-trivy".

Quoi - Des attaquants ont réussi à publier ou remplacer des tags GitHub malveillants liés à ces actions. Au total, 75 tags compromis ont été identifiés et rendaient disponibles des artefacts contenant du code conçu pour voler des secrets présents dans les runners GitHub Actions¹.

Quand - Une première compromission avait déjà eu lieu un mois auparavant, mais elle était alors passée inaperçue. Les événements récents montrent une campagne répétée visant l'écosystème Trivy¹.

Où - Les artefacts compromis étaient stockés et distribués via GitHub. Les workflows qui consomment ces actions, que ce soit depuis le marketplace ou par référence directe, ont pu télécharger des versions compromises.

Comment - Les attaquants ont exploité la confiance attachée aux tags GitHub en mettant à jour ou en remplaçant des tags existants. Ce type d'attaque s'appuie souvent sur des comptes ou tokens mainteneurs mal protégés, ou sur des processus de publication insuffisamment sécurisés. En injectant un composant malveillant, les attaquants ont pu exécuter du code côté runner, rechercher des secrets injectés dans l'environnement et exfiltrer les informations vers des serveurs externes¹.

Chronologie technique synthétique

Compromission initiale (mois précédent) : premier incident détecté dans l'écosystème Trivy, utilisé comme phase de reconnaissance et de préparation par les attaquants¹.
Nouvelle compromission : 75 tags compromis rendus publics et disponibles pour les workflows ciblés¹.
Détection : la communauté a alerté les mainteneurs, ce qui a déclenché des actions correctives d'Aqua Security et des interventions de GitHub via leurs procédures de sécurité² ^³.

Contexte

Trivy est largement adopté dans les chaînes CI/CD pour scanner les images conteneur et les dépendances. Cette popularité en fait une cible prioritaire pour des attaques contre la chaîne d'approvisionnement logicielle. Les incidents récents s'inscrivent dans une tendance où des outils ou packages très utilisés sont ciblés pour maximiser l'impact.

Risques liés aux artefacts GitHub Actions

Les GitHub Actions exécutent du code qui peut disposer d'accès aux secrets injectés dans le workflow. Si une action compromise s'exécute avec ces secrets, le code malveillant peut les lire et les envoyer vers l'extérieur. GitHub propose des protections (limitation de partage des secrets aux forks, environnements avec approbation, contrôle des permissions des tokens), mais ces mesures ne suffisent pas si elles ne sont pas correctement configurées ou si des comptes mainteneurs sont compromis² ^³.

Précédents similaires

Le paysage logiciel a été marqué par des incidents où des paquets npm, PyPI ou d'autres artefacts imitaient des librairies populaires pour tromper les développeurs. La répétition des compromissions autour de Trivy indique que des vecteurs connus n'ont pas toujours été corrigés ou que la campagne actuelle exploite plusieurs failles opérationnelles en parallèle¹.

Réactions et conséquences

Réactions officielles

Aqua Security et les mainteneurs ont supprimé les tags compromis et publié des recommandations à destination des utilisateurs. GitHub, de son côté, a activé ses processus de signalement et de retrait pour contenir la diffusion des artefacts malveillants² ^³.

Impacts opérationnels immédiats

Si des workflows ont exécuté des versions compromises, deux enjeux critiques se posent : la compromission des secrets et l'interruption des pipelines. Parmi les conséquences concrètes possibles :

Accès non autorisé à des registres de conteneurs, ouvrant la voie à des injections d'images malveillantes.
Utilisation de clés compromises pour déployer du code non autorisé en production.
Exfiltration de données sensibles à partir des environnements cloud.

Coûts directs et indirects

La rotation des secrets, les enquêtes forensiques, les audits et le temps d'arrêt des pipelines peuvent générer des coûts significatifs, parfois des dizaines ou centaines de milliers d'euros, voire plus en cas d'usage frauduleux de ressources cloud.

Conséquences réglementaires et contractuelles

La fuite de secrets ou de données personnelles peut entraîner des obligations de notification et des sanctions au titre du RGPD, ainsi que des pénalités contractuelles en cas de rupture d'engagement de sécurité.

Exemple d'impact opérationnel concret

Une organisation qui utilise "aquasecurity/trivy-action" dans 200 workflows et dont 10 % des workflows exposent des secrets sensibles pourrait devoir réinitialiser et faire tourner des centaines de secrets, suspendre des pipelines et mener des analyses pour déterminer l'étendue réelle de l'exposition.

Recommandations opérationnelles et techniques

Actions immédiates (jours 0-3)

Identifier et isoler - Dressez la liste de tous les workflows qui référencent "aquasecurity/trivy-action" ou "aquasecurity/setup-trivy". Remplacez temporairement ces références par des versions locales ou des artefacts vérifiés.
Révoquer et faire tourner les secrets exposés - Faites immédiatement la rotation des tokens GitHub, des clés cloud et des identifiants Docker Registry susceptibles d'avoir été utilisés dans les workflows compromis.
Restreindre les permissions - Appliquez le principe du moindre privilège aux tokens et revoyez les autorisations des comptes de service.
Quarantaine et collecte de preuves - Mettez en quarantaine les runners suspects, collectez les logs d'exécution (actions, processus enfants, réseau) et conservez les preuves pour une analyse forensique.

Mesures à moyen terme (semaines)

Basculer vers des références immuables - Privilégiez l'utilisation de digests d'images (sha256) ou de releases signées plutôt que des tags flottants.
Signer et vérifier les artefacts - Adoptez des chaînes de confiance (Sigstore, cosign, rekor) pour vérifier l'intégrité des artefacts consommés.
Renforcer la gouvernance des mainteneurs - Imposer l'authentification à facteurs multiples (MFA), des revues de comptes et des processus de publication robustes pour les mainteneurs.
Détection et monitoring - Intégrez des règles SIEM/EDR visant les runners pour repérer les exfiltrations réseau et les comportements anormaux.

Bonnes pratiques pour les workflows GitHub Actions

Désactivez le partage automatique des secrets avec les forks quand ce n'est pas nécessaire.
Utilisez des environnements GitHub nécessitant des approbations manuelles pour les déploiements en production.
Préférez les actions signées et vérifiez l'historique et la réputation des mainteneurs.
Maintenez un miroir interne des actions critiques et automatisez la vérification d'intégrité.

Checklist technique rapide

Rechercher toutes les références à "aquasecurity/trivy-action" et "aquasecurity/setup-trivy" dans vos dépôts.
Remplacer ces références par des versions pinées via digest ou par un wrapper interne vérifié.
Faire tourner tous les secrets potentiellement exposés.
Lancer une enquête forensique sur les runners concernés et analyser le trafic réseau sortant.

Agir vite, mais agir juste : la rotation des secrets est indispensable, mais elle doit s'accompagner d'une investigation qui permette d'évaluer l'étendue réelle des compromissions et d'empêcher une réapparition du problème. Les équipes DevOps et sécurité doivent coordonner leurs réponses pour réduire la surface d'attaque et restaurer des chaînes de distribution fiables.

Questions fréquentes

Comment savoir si mon pipeline a utilisé une version compromise de Trivy ?

Recherchez toutes les occurrences de "aquasecurity/trivy-action" et "aquasecurity/setup-trivy" dans vos workflows. Inspectez les digests et les timestamps des runs, vérifiez les logs d'exécution et cherchez tout trafic réseau sortant non expliqué pendant les runs suspects. Si l'un des tags identifiés parmi les 75 compromis a été employé, considérez les secrets potentiellement exposés et lancez une rotation immédiate des identifiants¹.

La simple rotation des secrets suffit-elle à remédier au problème ?

La rotation est nécessaire mais pas suffisante. Il faut aussi déterminer l'étendue de l'exposition, mener une analyse forensique des runners, vérifier si des actions non autorisées ont été effectuées avec les secrets et corriger les pratiques de distribution des artefacts (digests, signatures, mirrors internes). Une enquête technique permet de prioriser les rotations et de limiter l'impact opérationnel¹ ².

Quelles protections GitHub appliquer en priorité pour limiter ce risque ?

Désactivez le partage automatique de secrets avec les forks si ce n'est pas requis, utilisez des environnements avec approbation manuelle pour les déploiements sensibles, appliquez le moindre privilège aux tokens CI/CD et imposez le MFA aux comptes mainteneurs. Privilégiez les actions signées et vérifiez l'historique des mainteneurs² ³.

Doit-on arrêter d'utiliser des actions publiques ?

Pas nécessairement. Il faut réduire le risque : mirrorer les actions critiques en interne, utiliser des digests et des signatures, auditer les mainteneurs et automatiser les vérifications d'intégrité. Adoptez une posture de confiance zéro pour la supply chain logicielle et conservez un inventaire des artefacts approuvés.

Quels outils aident à vérifier l'intégrité des artefacts ?

Sigstore (cosign, rekor) permet de signer et vérifier les artefacts. Les SBOM, les scanners de vulnérabilités complémentaires et les solutions de gestion des secrets (Vault, AWS Secrets Manager, GitHub Secrets avec environnements et approbations) renforcent la traçabilité et la protection des secrets³.