Attaque par chaîne d’approvisionnement sur Trivy : quand l’outil de sécurité devient une arme
8 min de lecture
Le 19 mars 2026, le populaire scanner de vulnérabilités Trivy est devenu lui-même une cible d’attaque. 75 des 76 balises de version du dépôt GitHub ont été compromises, un binaire falsifié ayant volé des clés SSH, des identifiants cloud et des secrets Kubernetes depuis des pipelines CI/CD. Cette attaque révèle un schéma qui s’accentue en 2026 : les attaquants ne visent plus les applications – ils ciblent désormais les outils censés les sécuriser.
Selon le rapport de situation du BSI (Office fédéral de la sécurité informatique) 2025, les attaques par chaîne d’approvisionnement ont doublé en Allemagne. Le délai moyen de détection s’élève à 287 jours – près de dix mois durant lesquels du code compromis s’exécute sans être détecté dans des environnements de production. Toute organisation développant, achetant ou exploitant des logiciels doit considérer sa propre chaîne d’approvisionnement comme une surface d’attaque. Cet article montre, à travers des cas récents, ce qui se produit, quels schémas se répètent – et quelles mesures concrètes sont efficaces.
L’essentiel
- Attaque sur Trivy, mars 2026 : 75 balises de version compromises, un voleur d’informations en trois étapes extrayant des secrets CI/CD vers un domaine de typosquattage. Affecté : des milliers d’équipes DevSecOps dans le monde entier (Aqua Security, CrowdStrike, Wiz).
- 156 % de plus de paquets open source malveillants en comparaison annuelle. Depuis 2019, plus de 704 000 paquets malveillants ont été identifiés (Sonatype 2024).
- 74 % des bases de code contiennent des vulnérabilités open source à haut risque (Synopsys OSSRA 2024).
- La SBOM devient obligatoire : l’acte européen sur la résilience cybernétique oblige les fabricants à fournir une nomenclature logicielle lisible par machine. Principales obligations à partir de décembre 2027, obligations de déclaration à partir de septembre 2026.
- BSI : 119 nouvelles vulnérabilités par jour – une hausse de 24 %. 48 % des exploitants KRITIS sans système de détection d’attaques (rapport de situation BSI 2025).
L’attaque sur Trivy : quand le scanner devient un cheval de Troie
Trivy est l’un des scanners open source de vulnérabilités les plus utilisés dans le domaine DevSecOps. Il analyse les images de conteneurs, les systèmes de fichiers et les modèles IaC pour détecter les failles, et s’exécute dans des milliers de pipelines CI/CD sous forme d’action GitHub. C’est précisément là que les attaquants ont frappé.
Le groupe « TeamPCP » a compromis fin février 2026 les identifiants des actions GitHub du projet Trivy. La première réaction d’Aqua Security est restée incomplète – la rotation des identifiants n’a pas couvert tous les accès. Le 19 mars a suivi la deuxième vague : 75 des 76 balises de version du dépôt aquasecurity/trivy-action ont été redirigées vers du code malveillant par un « force-push ». Les sept balises du dépôt aquasecurity/setup-trivy étaient également affectées.
Le code infiltré fonctionnait en trois étapes. Premièrement : récupération des variables d’environnement et des identifiants depuis la mémoire du runner CI/CD. Deuxièmement : chiffrement des données sensibles – clés SSH, identifiants cloud, jetons de base de données, secrets Kubernetes. Troisièmement : exfiltration vers le domaine de typosquattage scan.aquasecurtiy[.]org – un nom de domaine délibérément mal orthographié.
L’ironie : un outil conçu pour détecter les vulnérabilités est devenu une vulnérabilité en soi. Cette attaque aurait pu être largement évitée grâce au pinnage basé sur le hachage SHA des actions GitHub. Toute personne ayant référencé un hash de commit spécifique au lieu de trivy-action@v0.35.0 n’aurait pas été affectée par le « tag poisoning ».
Le schéma : XZ Utils, 3CX et la stratégie à long terme
Les attaques par chaîne d’approvisionnement suivent de plus en plus un schéma précis : construire la confiance, compromettre l’infrastructure, propager largement.
L’exemple le plus frappant est la porte dérobée dans XZ-Utils de mars 2024 (CVE-2024-3094, CVSS 10,0). Un attaquant utilisant le pseudonyme « Jia Tan » a établi la confiance auprès du mainteneur de cette bibliothèque de compression largement répandue pendant trois ans. À la fin, il a implanté une porte dérobée permettant une exécution de code à distance via OpenSSH – dans un composant présent sur pratiquement tous les serveurs Linux. L’attaque a été découverte par hasard : le développeur PostgreSQL Andres Freund a remarqué un ralentissement inhabituel lors des connexions SSH.
Dans l’attaque 3CX (mars 2023), Mandiant a documenté pour la première fois une « double compromission de la chaîne d’approvisionnement » : le groupe Lazarus a d’abord compromis le logiciel de trading X_Trader, infecté via celui-ci un employé de 3CX, puis manipulé les environnements de compilation. L’application de bureau signée a été distribuée à 600 000 entreprises et 12 millions d’utilisateurs.
Le schéma commun à ces trois cas : le vecteur d’attaque n’était pas l’application elle-même, mais l’infrastructure derrière celle-ci. Systèmes de compilation, dépôts de code, registres de dépendances. Toute organisation qui sécurise uniquement son application tout en accordant une confiance aveugle aux outils et dépendances présente une faille ouverte de plus en plus exploitée. Gartner prévoyait en 2022 que d’ici 2025, 45 % des organisations subiraient des attaques sur leur chaîne d’approvisionnement logicielle. Un sondage BlackBerry de 2024 révèle : ce chiffre est déjà de 75 %.
« La gestion des risques liés à la chaîne d’approvisionnement reste l’un des plus grands problèmes pour les DSI. »
– Philip Reitinger, PDG de Global Cyber Alliance, selon (SecurityWeek Cyber Insights 2024)
Les chiffres : pourquoi le problème croît de manière exponentielle
Le rapport Sonatype State of Software Supply Chain 2024 documente une hausse de 156 % des paquets open source malveillants en comparaison annuelle. Depuis 2019, plus de 704 000 paquets malveillants ont été identifiés dans des registres comme npm, PyPI et Maven – dont plus de 512 000 rien qu’à partir de novembre 2023.
Le rapport Synopsys OSSRA 2024 complète ces données : 96 % des bases de code analysées contiennent des composants open source. 84 % contiennent au moins une vulnérabilité connue. 74 % contiennent des vulnérabilités à haut risque – une augmentation de 54 % par rapport à l’année précédente. Et 91 % utilisent des composants obsolètes de dix versions ou plus.
S’ajoute un nouveau phénomène : le « slopsquatting » – les attaquants profitent de la tendance des assistants de code IA à « halluciner » des noms de paquets inexistants. Ils enregistrent ces noms et y insèrent du code malveillant. Lorsqu’un développeur adopte sans vérification la suggestion de l’IA, le logiciel malveillant est automatiquement installé.
Le problème du « slopsquatting » est particulièrement insidieux car il croît avec la diffusion des assistants de codage IA. Selon ReversingLabs, 14 des 23 campagnes de logiciels malveillants liés aux cryptomonnaies en 2024 ciblaient déjà des paquets npm. En septembre 2025, 20 paquets npm ont été compromis, totalisant ensemble plus de deux milliards de téléchargements hebdomadaires. La surface d’attaque ne croît donc pas de manière linéaire – elle augmente avec chaque nouveau paquet installé par un développeur, avec chaque nouvelle dépendance automatiquement résolue par un système de compilation. Et selon Sonatype, dans 95 % des cas où les développeurs utilisent un composant vulnérable, une version corrigée existe déjà. Le problème n’est pas la disponibilité des correctifs – c’est le manque d’attention porté aux mises à jour.
Les coûts sont mesurables : selon le rapport IBM Cost of a Data Breach 2024, le coût moyen d’une violation de données s’élève à 4,88 millions de dollars – un record historique. Les compromissions de chaînes d’approvisionnement étaient légèrement supérieures selon les analyses IBM et constituaient le deuxième vecteur d’attaque le plus fréquent.
Pour les entreprises allemandes, la situation s’aggrave en raison de deux évolutions parallèles. Premièrement : le règlement NIS2 rend la sécurité de la chaîne d’approvisionnement obligatoire pour environ 29 500 entreprises – y compris la responsabilité personnelle des dirigeants en cas de négligence. Deuxièmement : la pénurie de personnel qualifié en cybersécurité signifie que de nombreuses entreprises n’ont pas assez de ressources pour examiner systématiquement leurs dépendances. Le BSI rapporte que 80 % des exploitants KRITIS ont bien mis en place des systèmes de management de la sécurité de l’information – mais présentent de graves lacunes en matière de gestion de la continuité d’activité. Lorsqu’une dépendance critique est compromise et qu’aucun plan de réponse aux incidents n’existe, les 287 jours jusqu’à la détection s’avèrent particulièrement douloureux.
Pourquoi les outils de sécurité classiques ne suffisent pas
La sécurité des entreprises repose majoritairement sur un modèle qui ne couvre pas les attaques par chaîne d’approvisionnement : protection du périmètre, détection au niveau des terminaux, segmentation réseau. Ces outils détectent les logiciels malveillants provenant de l’extérieur – mais pas le code malveillant introduit via des canaux de confiance.
Dans l’attaque sur Trivy, le code malveillant est arrivé via un outil explicitement utilisé comme mesure de sécurité. Aucun antivirus n’aurait déclenché d’alerte, aucun journal de pare-feu n’aurait montré d’anomalie. L’attaque exploitait le pipeline CI/CD normal – les mêmes chemins que ceux utilisés pour la diffusion de code légitime. Pour les systèmes de détection d’intrusion, tout semblait parfaitement normal.
C’est pourquoi les tests d’intrusion traditionnels échouent également face aux risques liés à la chaîne d’approvisionnement. Un test d’intrusion examine l’infrastructure propre à l’entreprise – pas les systèmes de compilation des projets open source utilisés comme dépendances. Et un audit de la base de code propre ne détectera pas une porte dérobée dans une dépendance en amont nichée 50 versions plus bas.
Ce dont on a besoin à la place : un déplacement vers l’amont (Shift Left) dans la chaîne d’approvisionnement – des contrôles de sécurité non plus seulement en fin de pipeline, mais sur chaque dépendance individuelle. Cela signifie : chaque paquet est vérifié dès son intégration dans la base de code, pas seulement au déploiement. Chaque action GitHub est verrouillée par SHA, pas référencée par balise. Et chaque processus de compilation est signé et vérifié cryptographiquement – avant qu’un seul octet n’atteigne la production.
Le changement de paradigme est comparable à l’introduction de la confiance zéro (Zero Trust) dans les réseaux : non plus « tout ce qui est à l’intérieur du périmètre est de confiance », mais « rien n’est de confiance tant qu’il n’a pas été vérifié » – et cela inclut les propres outils de développement.
Allemagne : 119 vulnérabilités par jour et l’obligation de SBOM
Le rapport de situation du BSI 2025 documente 119 nouvelles vulnérabilités de sécurité par jour sur la période analysée – une hausse de 24 %. 461 fuites de données avec des institutions allemandes comme victimes. Et 48 % des exploitants KRITIS ne disposent d’aucun système de détection d’attaques.
L’acte européen sur la résilience cybernétique (en vigueur depuis le 10 décembre 2024) oblige tous les fabricants de produits contenant des éléments numériques à fournir une SBOM lisible par machine. Principales obligations à partir du 11 décembre 2027, obligations de déclaration à partir du 11 septembre 2026. Sanctions : jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel.
Le BSI a défini des exigences concrètes pour la SBOM avec la norme TR-03183-2 (août 2025). Formats recommandés : SPDX et CycloneDX. Pour les entreprises régulées par NIS2, la sécurité de la chaîne d’approvisionnement fait déjà explicitement partie des exigences légales.
aux États-Unis, l’ordonnance exécutive 14028 de 2021 s’applique : tout fournisseur de logiciels livrant au gouvernement fédéral doit fournir une SBOM. La date limite de mise en œuvre était septembre 2023. L’Europe suit avec le CRA – et va même plus loin que la réglementation américaine avec les obligations de déclaration à partir de septembre 2026. Pour les PME allemandes livrant à la fois aux États-Unis et à l’UE, cela signifie : la SBOM n’est pas optionnelle – c’est une condition d’accès au marché des deux côtés de l’Atlantique.
La dimension financière est considérable : selon le rapport IBM Cost of a Data Breach 2024, le coût moyen d’un incident lié à la chaîne d’approvisionnement s’élève à près de 5 millions de dollars. Pour une PME de 500 employés, cela peut menacer son existence – surtout si le délai de détection atteint près de dix mois et que d’autres systèmes sont compromis durant cette période. S’ajoutent les conséquences réglementaires : sous NIS2, des amendes pouvant atteindre 10 millions d’euros et la responsabilité personnelle des dirigeants sont possibles en cas de sécurité insuffisante de la chaîne d’approvisionnement. Avec le CRA, jusqu’à 15 millions d’euros supplémentaires peuvent être ajoutés. Les coûts de prévention – outils SBOM, analyse des dépendances, un demi-temps équivalent pour la sécurité de la chaîne d’approvisionnement – se situent dans la fourchette des cinq chiffres par an. Le rapport entre investissement et dommage potentiel justifie chacune de ces mesures.
Ce qui protège concrètement : six mesures éprouvées
1. Pinnage des dépendances basé sur SHA. Plutôt que de référencer les actions GitHub par balise (@v1), verrouiller le hash de commit précis. Les balises peuvent être écrasées, les hachages SHA non. L’attaque entière sur Trivy aurait échoué.
2. Créer et maintenir une SBOM. Celui qui ignore quelles dépendances sont intégrées à son logiciel ne peut pas réagir à la prochaine alerte CVE. Des outils comme Syft génèrent automatiquement des SBOM à partir d’images de conteneurs.
3. Mettre en œuvre SLSA Niveau 2. Le cadre « Supply-chain Levels for Software Artifacts » garantit l’intégrité de la compilation. Le niveau 2 – provenance de compilation signée numériquement – est atteignable en quelques semaines avec cosign et GitHub-OIDC.
4. Analyse des dépendances dans le pipeline CI/CD. Vérification automatisée de chaque dépendance à chaque compilation. Outils : Dependabot, Snyk, Grype. Aucun push sans contrôle de sécurité validé.
5. Signature de code avec Sigstore. Gratuit, open source, permet des signatures cryptographiques pour binaires et paquets. Les manipulations deviennent détectables.
6. Évaluation régulière des risques fournisseurs. Ne pas seulement examiner son propre logiciel – mais aussi les fournisseurs. Celui qui utilise un scanner de vulnérabilités doit savoir si son pipeline CI/CD est sécurisé.
La combinaison de ces six mesures constitue le minimum requis pour une sécurité robuste de la chaîne d’approvisionnement. Aucune mesure isolée ne suffit. Le pinnage SHA sans analyse de dépendances ne détecte pas les vulnérabilités connues. Une SBOM sans évaluation fournisseur montre les dépendances internes, mais pas leur niveau de sécurité. Et la signature de code sans SLSA prouve seulement qui a signé – pas si le processus de compilation était propre. La force réside dans la combinaison : transparence (SBOM), intégrité (SLSA + signature), vérification (analyse + évaluation) et renforcement (pinnage).
Le point décisif : la sécurité de la chaîne d’approvisionnement n’est pas un projet qu’on termine une fois pour toutes. C’est un processus continu à intégrer dans chaque compilation, chaque déploiement et chaque décision d’achat. L’attaque sur Trivy a montré que même les outils censés garantir la sécurité peuvent être compromis. Celui qui a compris cela ne construit pas sa défense sur la confiance – mais sur la vérification.
« Les attaques contre la chaîne d’approvisionnement logicielle de notre infrastructure ICT mondiale deviennent plus fréquentes, plus agressives et plus dommageables. »
– CISA, Defending Against Software Supply Chain Attacks, selon
La leçon de 2024, 2025 et du premier trimestre 2026 est claire : les chaînes d’approvisionnement logicielles sont la nouvelle principale surface d’attaque. Celui qui les ignore repose sur la confiance dans un monde qui exige la vérification. Le cas Trivy est particulièrement instructif – non pas parce qu’il était techniquement nouveau, mais parce qu’il montre que même les outils de défense eux-mêmes sont vulnérables. La réponse n’est pas la méfiance envers l’open source. C’est la vérification systématique : chaque dépendance vérifiée, chaque compilation signée, chaque modification traçable. C’est fastidieux. Mais l’alternative – 287 jours avec du code compromis en production – l’est nettement plus.
Questions fréquentes
Qu’était l’attaque par chaîne d’approvisionnement sur Trivy ?
En mars 2026, le groupe TeamPCP a compromis le scanner open source de vulnérabilités Trivy d’Aqua Security. 75 des 76 balises de version du dépôt GitHub ont été redirigées vers du code malveillant. Le code infiltré a volé des secrets CI/CD comme les clés SSH, les identifiants cloud et les jetons Kubernetes.
Qu’est-ce qu’une SBOM et pourquoi devient-elle obligatoire ?
Une Software Bill of Materials est une nomenclature lisible par machine de tous les composants logiciels d’un produit. L’acte européen sur la résilience cybernétique la rend obligatoire à partir de décembre 2027. Les formats courants sont CycloneDX et SPDX.
Comment se protéger contre les attaques par chaîne d’approvisionnement ?
Les mesures les plus importantes : pinnage basé sur SHA des dépendances, analyse automatisée des dépendances dans le pipeline CI/CD, création et maintenance d’une SBOM, signature de code avec Sigstore et évaluation régulière des risques fournisseurs.
Qu’est-ce que le pinnage basé sur SHA ?
Plutôt que de référencer une action GitHub par balise de version (ex. @v1), utiliser le hash de commit précis. Les balises peuvent être écrasées par des attaquants, les hachages SHA non.
Combien de temps les attaques par chaîne d’approvisionnement restent-elles indétectées ?
Selon le rapport de situation du BSI 2025, le délai moyen de détection est de 287 jours. Pour la porte dérobée XZ-Utils, la phase de préparation a duré trois ans.
Quelles entreprises allemandes sont concernées ?
Toute entreprise utilisant ou exploitant des logiciels. Particulièrement exposées : les entreprises régulées par NIS2 (environ 29 500 en Allemagne) et les exploitants KRITIS.
Qu’est-ce que SLSA ?
Supply-chain Levels for Software Artifacts – un modèle en niveaux pour l’intégrité de la compilation. Le niveau 2 peut être mis en œuvre en quelques semaines avec cosign et GitHub-OIDC.
Lectures recommandées par la rédaction
Plus d’informations depuis le réseau MBF Media
Source de l’image : Pexels / Tima Miroshnichenko (px:5380603)
