Attaques supply chain : ce que Trivy, XZ et Polyfill.io changent pour vos déploiements

Le 19 mars 2026, un acteur disposant d’identifiants compromis a publié une version malveillante de Trivy et détourné les références de ses actions GitHub. Trivy est justement utilisé pour détecter des vulnérabilités dans les dépendances et les images de conteneurs.

L’incident ne rend pas le scanner inutile. Il rappelle qu’un outil de sécurité reste un logiciel distribué par une chaîne de build, des comptes, des registres et des mécanismes de mise à jour qui peuvent eux-mêmes être compromis.

Mise à jour du 28 août 2026 : cet article a été recentré sur les faits confirmés par les projets concernés. Plusieurs exemples historiques de la version initiale mélangeaient des dates ou des mécanismes d’attaque différents. Les commandes ont aussi été adaptées aux versions actuelles des outils cités.

En bref

#

• Trivy v0.69.4, 76 des 77 tags de trivy-action et les 7 tags de setup-trivy ont été détournés en mars 2026.
• Des images Docker Hub Trivy v0.69.5 et v0.69.6 ont également été publiées par l’attaquant.
• Une référence par tag est mutable. Un digest ou un commit complet fige le contenu récupéré.
• Un digest prouve l’identité d’un artefact, pas son origine ni son innocuité.
• Une signature est utile seulement si l’identité attendue et la politique de vérification sont contrôlées.
• Un SBOM facilite l’inventaire et la réponse à incident. Il ne détecte pas automatiquement un code malveillant.
• Le contrôle le plus rentable reste de limiter les secrets et permissions accessibles à chaque build.

Comment une chaîne logicielle est compromise

#

Une attaque de supply chain consiste à altérer un composant avant qu’il n’arrive dans l’environnement visé. Le point d’insertion peut être :

• le compte d’un mainteneur ;
• le dépôt source ou une balise Git ;
• une dépendance directe ou transitive ;
• le runner CI et ses secrets ;
• le processus de build ;
• le registre de paquets ou d’images ;
• un script chargé dynamiquement depuis un service tiers.

L’attaquant profite ensuite du chemin normal de consommation : mise à jour automatique, reconstruction d’une image, installation d’un paquet ou exécution d’une action CI.

Quatre incidents utiles à comparer

#

Trivy en 2026

#

Selon l’avis du projet, l’attaquant a utilisé des identifiants compromis pour publier Trivy v0.69.4 et déplacer 76 des 77 tags de aquasecurity/trivy-action vers du code malveillant. Les sept tags de aquasecurity/setup-trivy ont aussi été remplacés.

L’exposition a varié selon le composant : environ trois heures pour le binaire v0.69.4, douze heures pour trivy-action et quatre heures pour setup-trivy. Les 22 et 23 mars, les images Docker Hub v0.69.5 et v0.69.6 ont constitué une seconde fenêtre d’exposition d’environ dix heures.

La rotation de secrets réalisée après un incident précédent n’avait pas révoqué tous les accès de manière simultanée. Le retour d’expérience publié par l’équipe insiste depuis sur la révocation complète, le passage à des GitHub Apps et le durcissement du pipeline de publication.

XZ Utils en 2024

#

Les archives de publication XZ 5.6.0 et 5.6.1 contenaient une chaîne d’injection absente d’une partie des sources visibles dans Git. Dans certaines configurations Linux x86-64, le code modifiait le processus sshd par l’intermédiaire de liblzma et de libsystemd.

Andres Freund a découvert l’anomalie en enquêtant sur une consommation CPU inhabituelle et des erreurs Valgrind. L’incident montre l’intérêt de comparer les sources, les archives publiées et le résultat du build. Une signature valide de l’archive n’aurait pas suffi si le processus de publication lui-même était considéré comme légitime.

event-stream en 2018

#

Un nouveau mainteneur a ajouté flatmap-stream comme dépendance de event-stream. Le code malveillant ciblait spécifiquement le processus de build de l’application Copay et cherchait à récupérer les données de compte et les clés privées des portefeuilles dépassant certains soldes.

Le payload restait inactif dans la plupart des autres environnements. Cet exemple est important pour la détection : une dépendance peut être malveillante tout en restant silencieuse pendant les tests génériques.

Polyfill.io en 2024

#

Après la vente du domaine polyfill.io à un nouvel opérateur, le service a commencé en juin 2024 à injecter du JavaScript provoquant des redirections dans certaines conditions. Les sites concernés chargeaient le script à l’exécution depuis un domaine tiers.

Le code déployé pouvait donc changer sans nouvelle version de l’application consommatrice. Pour une ressource JavaScript distante, un nom de domaine historiquement fiable n’est pas une garantie d’intégrité durable.

Impact dans un homelab ou une petite équipe

#

La taille de l’infrastructure ne réduit pas le risque lié aux automatismes. Les mêmes habitudes apparaissent souvent :

• actions GitHub référencées par un tag ;
• images Docker en latest ;
• scripts installés avec curl | bash ;
• mises à jour automatiques sans étape de validation ;
• runner auto-hébergé ayant accès au socket Docker, au réseau interne et à plusieurs secrets.

Un petit environnement a généralement moins de secrets, mais aussi moins de journalisation et de séparation entre le lab, le poste d’administration et les services publics.

Vérifier son exposition

#

Cas Trivy de mars 2026

#

Rechercher les actions concernées dans les workflows :

rg -n 'aquasecurity/(trivy-action|setup-trivy)@' .github/workflows

L’avis officiel détaille les versions, commits et fenêtres horaires à comparer avec l’historique des jobs. Les composants malveillants incluent notamment :

• Trivy v0.69.4, distribué par plusieurs canaux ;
• les images Docker Hub v0.69.5 et v0.69.6 ;
• les tags de trivy-action antérieurs à 0.35.0 pendant la fenêtre indiquée ;
• les références non épinglées de setup-trivy pendant sa fenêtre d’exposition.

Si un job concerné a tourné avec des secrets, considérer ces secrets comme exposés. Il faut les révoquer, examiner les journaux des services associés et reconstruire le runner s’il est persistant.

Références GitHub Actions mutables

#

Inventorier toutes les actions tierces :

rg -n '^[[:space:]]*uses:[[:space:]]+[^./][^[:space:]]+@' .github/workflows

Une référence comme @v4 ou @main peut changer. GitHub recommande d’utiliser le SHA complet d’un commit pour une action tierce :

- uses: actions/checkout@<sha-complet-vérifié>

Conserver le numéro de version en commentaire aide Renovate ou Dependabot à proposer les mises à jour sans perdre la traçabilité.

Images de conteneurs

#

Lister les images et les digests connus localement :

docker image ls --digests

Rechercher les tags flottants dans les fichiers Compose :

rg -n '^[[:space:]]*image:[[:space:]].*:(latest|edge|main)(@|[[:space:]]|$)' \
  --glob 'compose*.yml' --glob 'compose*.yaml' --glob 'docker-compose*.yml' --glob 'docker-compose*.yaml'

Une référence par digest évite qu’un redéploiement récupère silencieusement un autre contenu :

image: registry.example/app:1.4.2@sha256:<digest>

Le tag reste informatif. Le digest est la valeur réellement immuable.

Secrets et permissions des workflows

#

Rechercher les permissions explicitement accordées :

rg -n '^[[:space:]]*(permissions|id-token|contents|packages|pull-requests):' .github/workflows

L’absence de résultat n’est pas nécessairement rassurante, car les permissions par défaut dépendent du dépôt et de l’organisation. Définir permissions: read-all au niveau global, puis ouvrir seulement les droits nécessaires pour chaque job, réduit l’impact d’une action compromise.

Contrôles qui apportent réellement quelque chose

#

Épingler, puis automatiser les mises à jour

#

Épingler un commit ou un digest supprime la mutation silencieuse. Cela crée en contrepartie une dette de mise à jour. Renovate ou Dependabot peuvent ouvrir des changements explicites, qui passent ensuite par la CI et la revue.

Le pinning ne protège pas si l’artefact était déjà malveillant au moment où il a été choisi. Il rend surtout le changement visible et reproductible.

Vérifier signature et provenance

#

Avec cosign, la vérification doit préciser l’identité attendue et l’émetteur OIDC, selon la politique publiée par le projet. Une simple commande cosign verify sans contrôler l’identité accepte un modèle de confiance trop large.

La provenance complète la signature en décrivant le dépôt source, le workflow et le builder. SLSA v1.2 définit trois niveaux pour la piste Build :

• Build L1 : une provenance existe ;
• Build L2 : elle est authentique et produite par un service de build hébergé ;
• Build L3 : le service de build apporte des garanties d’isolation et rend la provenance non falsifiable par les étapes du build.

SLSA ne prouve pas que le code source est sûr. Il aide à vérifier que l’artefact correspond au processus attendu.

Produire un SBOM

#

Syft peut générer un inventaire CycloneDX d’une image :

syft nginx:stable -o cyclonedx-json > nginx.cdx.json

Un SBOM accélère la réponse lorsqu’une bibliothèque est annoncée vulnérable. Il ne détecte ni un script malveillant inconnu, ni un compte de mainteneur compromis.

Scanner les dépendances connues

#

Avec OSV-Scanner v2 :

osv-scanner scan source -r .
osv-scanner scan image nginx:stable

Ces scans recherchent des vulnérabilités connues dans les composants détectés. Ils ne remplacent pas la vérification de provenance ou l’analyse comportementale.

Réduire la valeur du runner

#

Un runner CI ne devrait recevoir que les secrets nécessaires au job courant. Les contrôles utiles sont :

• jetons courts obtenus par OIDC plutôt que secrets cloud persistants ;
• permissions GitHub minimales ;
• environnement éphémère ou reconstruit après chaque job sensible ;
• séparation entre builds provenant de branches fiables et contributions externes ;
• absence de secrets dans un job déclenché par une pull request non fiable ;
• filtrage et journalisation des connexions sortantes quand l’environnement le permet.

Plan d’action raisonnable

#

Pour un dépôt ou un homelab, l’ordre suivant couvre l’essentiel :

1. inventorier les actions, images et scripts téléchargés à l’exécution ;
2. remplacer les références flottantes par des commits ou digests complets ;
3. configurer Renovate ou Dependabot pour maintenir ces références ;
4. réduire les permissions et secrets de chaque workflow ;
5. vérifier les signatures et attestations quand le fournisseur en publie ;
6. produire un SBOM pour les images et applications importantes ;
7. conserver les journaux de build et de registre assez longtemps pour enquêter sur une fenêtre d’exposition ;
8. documenter une procédure de révocation des secrets et de reconstruction des runners.

Conclusion

#

Une chaîne logicielle ne devient pas sûre parce qu’elle utilise un scanner, une signature ou un SBOM. Chaque contrôle répond à une question différente : quel contenu a été utilisé, qui l’a publié, comment il a été construit et quels droits il a reçus à l’exécution.

Pour une petite infrastructure, les gains les plus immédiats viennent du pinning, des mises à jour explicites et de la réduction des secrets accessibles aux runners. Les outils plus avancés deviennent utiles ensuite, quand une politique de vérification permet réellement de refuser un artefact inattendu.

Sources

#

Sources vérifiées le 28 août 2026 :

• Trivy - avis GHSA-69fq-xp46-6x23 et fenêtres d’exposition
• Trivy - retour d’expérience et mesures correctives
• oss-security - divulgation initiale de la backdoor XZ Utils
• npm - analyse de l’incident event-stream
• Cloudflare - injection de code via polyfill.io en juin 2024
• GitHub - sécurisation des workflows Actions
• SLSA v1.2 - exigences de la piste Build
• Sigstore - documentation cosign
• Syft - génération de SBOM
• OSV-Scanner - analyse des sources et images