En mars 2026, quatre outils utilisés quotidiennement dans des pipelines CI/CD partout dans le monde — Trivy, Checkmarx KICS, LiteLLM et une dépendance de axios — se sont retrouvés compromis en l’espace de deux semaines. Pas des outils obscurs : des scanners de sécurité et des librairies que des dizaines de milliers d’équipes exécutent en confiance, sans y penser, à chaque build. Si ta pipeline CI/CD ressemble à la plupart — des actions tierces épinglées sur un tag, des secrets stockés en clair, aucune vérification de provenance sur ce qui sort en production — ces incidents te concernent directement. On fait le point sur ce qui s’est passé, les schémas d’attaque qui reviennent, et surtout les défenses concrètes à mettre en place sur Azure DevOps ou GitHub Actions.
Ce qui s’est passé en mars 2026
Entre le 19 et le 31 mars 2026, une série de compromissions a touché des composants au cœur de nombreuses pipelines CI/CD, comme l’a documenté l’analyse post-mortem publiée par GitLab :
- Trivy, le scanner de vulnérabilités utilisé dans d’innombrables jobs de scan de conteneurs, a été compromis par un malware volant les secrets présents dans l’environnement d’exécution.
- Checkmarx KICS, un scanner IaC largement utilisé pour auditer du Terraform et du Bicep, a subi une injection similaire de vol de credentials.
- LiteLLM, une passerelle vers des API de LLM de plus en plus intégrée dans les workflows d’automatisation, a livré des versions PyPI trojanisées contenant des backdoors.
- Une dépendance transitive de axios (le module
plain-crypto-js) s’est révélée malveillante, touchant potentiellement tout projet JavaScript qui l’incluait sans le savoir.
Un cinquième incident, distinct mais révélateur du même laxisme ambiant, a montré des source maps npm non filtrées exposant du code source en production.
Trois schémas d’attaque qui reviennent
Ce n’est pas un hasard si ces incidents se ressemblent. Ils exploitent trois failles structurelles qu’on retrouve dans la grande majorité des pipelines :
La confiance implicite envers les outils et actions
Une action GitHub référencée par un tag mutable (@v3 plutôt qu’un digest de commit), une image Docker tirée par son tag latest, un scanner installé sans vérification de checksum : autant de points où tu fais confiance à ce qui a été publié la dernière fois que tu as regardé, pas à ce qui tourne réellement aujourd’hui.
Les erreurs de configuration
Artefacts de debug oubliés dans un build de production, logs verbeux qui exposent des tokens, permissions de pipeline trop larges par défaut — ces erreurs classiques transforment une simple compromission d’outil en fuite de données complète.
La propagation par dépendances transitives
Tu audites peut-être tes dépendances directes. Mais une seule version compromise, plusieurs niveaux en dessous dans l’arbre de dépendances, se propage silencieusement à tout ce qui en dépend — comme l’a montré l’incident axios.
Les défenses concrètes à mettre en place
Passer à une authentification sans secret
La première chose qu’un attaquant cherche dans une pipeline compromise, ce sont des secrets à long terme : tokens Azure, clés d’API, mots de passe de service principal. La parade recommandée par Microsoft dans le Cloud Adoption Framework est de basculer sur l’authentification par fédération d’identité (OpenID Connect) pour tes connexions de service Azure DevOps comme pour tes workflows GitHub Actions — plus aucun secret client à stocker, donc plus rien à voler. On a détaillé la mise en œuvre côté Azure DevOps dans notre article sur la fédération d’identité pour les service connections.
Épingler aux digests, jamais aux tags
Un tag comme actions/checkout@v4 peut techniquement pointer vers un commit différent demain si le mainteneur (ou un attaquant ayant compromis son compte) le déplace. Épingler sur le digest SHA immuable (actions/checkout@a1b2c3d...) garantit que tu exécutes exactement le code que tu as audité, pas une version substituée après coup. Le même principe s’applique à tes images de base Docker : préfère un digest à un tag latest ou même à un tag de version.
Générer un SBOM et scanner tes dépendances en continu
Un inventaire à jour de tout ce qui compose ton build (SBOM — Software Bill of Materials) est ce qui te permet de répondre en quelques minutes, et non en plusieurs jours, à la question « est-ce qu’on utilise le composant compromis ?» le jour où un incident comme celui de mars 2026 est annoncé. Couplé à une analyse de composition logicielle (SCA) et à des outils comme Dependabot pour la mise à jour automatique des dépendances vulnérables, c’est la base d’une hygiène supply chain sérieuse.
Vérifier la provenance de ce que tu déploies
Les attestations de provenance (SLSA, Supply-chain Levels for Software Artifacts) permettent de prouver cryptographiquement qu’un artefact a bien été construit par ta pipeline, à partir du code source attendu, et qu’il n’a pas été substitué entre le build et le déploiement. GitHub propose nativement les Artifact Attestations, qui permettent d’atteindre le niveau SLSA 3 sans infrastructure supplémentaire à opérer toi-même. Encore émergent début 2026 mais à surveiller de près : les fonctionnalités de type « Dependency Firewall » qui bloquent automatiquement l’installation de versions connues comme compromises, avant même l’exécution du job.
Isoler tes runners self-hébergés
Un runner self-hosted partagé entre plusieurs projets, avec un accès réseau large et une identité trop permissive, est une cible de choix : une seule pipeline compromise donne potentiellement accès à tout ce que ce runner peut atteindre. Isole tes runners par niveau de confiance (production vs. développement), limite leurs permissions réseau sortantes, et évite de leur attacher des identités managées avec des droits qui dépassent largement ce dont un job donné a besoin.
Une checklist pour ta prochaine revue de pipeline
Avant ta prochaine passe de sécurisation, vérifie que tu coches ces points, qu’on ait affaire à GitHub Actions, Azure Pipelines ou GitLab CI :
- Aucun secret à longue durée de vie dans les pipelines : authentification via OIDC / workload identity federation partout où c’est possible
- Actions et images tierces épinglées par digest, pas par tag
- SBOM généré à chaque build et scan de dépendances actif (Dependabot ou équivalent)
- Attestations de provenance activées sur les artefacts qui partent en production
- Approbations obligatoires sur les modifications de configuration CI/CD elle-même, pas seulement sur les déploiements
- Runners self-hébergés isolés par niveau de confiance, avec des permissions réseau et des identités minimales
FAQ
Le passage aux digests casse-t-il les mises à jour automatiques de dépendances ?
Non, à condition d’utiliser un outil comme Dependabot ou Renovate qui sait résoudre et mettre à jour les digests automatiquement via des pull requests — tu gardes la traçabilité et la revue humaine, sans revenir à un tag mutable.
Faut-il migrer toutes les pipelines d’un coup ?
Non, commence par les pipelines qui déploient en production et celles qui manipulent des secrets sensibles. L’authentification sans secret et l’épinglage par digest sont les deux mesures avec le meilleur ratio effort/impact pour démarrer.
Les attestations SLSA sont-elles seulement pour GitHub Actions ?
Le concept est indépendant de la plateforme : GitHub propose une implémentation native, mais des équivalents existent ou émergent pour Azure Pipelines et GitLab CI via des outils tiers comme Sigstore/cosign.
Passe à l’action
Les incidents de mars 2026 n’ont épargné personne parce qu’ils ciblaient l’angle mort classique : la confiance aveugle envers ce qui tourne « habituellement » dans une pipeline. Prends une heure cette semaine pour auditer tes connexions de service, vérifie si tes actions critiques sont épinglées par tag ou par digest, et active un scan de dépendances si ce n’est pas déjà fait. Ce sont trois changements simples qui réduisent drastiquement ta surface d’attaque, sans ralentir tes déploiements.
Laisser un commentaire