245 millions de téléchargements piégés — j’ai passé 9 heures à auditer nos Cargo.lock, voici les 4 réflexes que j’ai gardés

J’ai lu la dépêche un jeudi matin en pensant y consacrer vingt minutes. J’ai refermé mon terminal neuf heures plus tard, avec deux dépôts internes modifiés et une conviction déplacée sur ce qu’est réellement une dépendance.

Le titre exact, publié le 20 août 2026, est « Rust Supply Chain Attack Puts Build-Time Malware in Crates with 245 Million Downloads ». Trois éléments dans cette phrase méritent qu’on s’arrête : supply chain, build-time, et 245 millions. Le troisième fait les gros titres. C’est le deuxième qui devrait vous empêcher de dormir.

Parce qu’un malware qui s’exécute à la compilation ne suit pas les règles que nous avons intégrées depuis vingt ans sur la gestion des dépendances. Il ne s’active pas quand le programme tourne. Il s’active quand vous tournez.

Pourquoi « build-time » change la nature du risque

Le modèle mental dominant sur les dépendances malveillantes est le suivant : j’importe une bibliothèque, elle contient une porte dérobée, cette porte dérobée s’ouvre quand mon application s’exécute en production. Le raisonnement est confortable parce qu’il implique que la production est la zone de danger, et que le poste du développeur est un environnement de préparation sans enjeu.

Rust, comme beaucoup d’écosystèmes modernes, permet à un paquet de fournir un script exécuté avant la compilation. Cette fonctionnalité existe pour de bonnes raisons — générer du code, détecter des bibliothèques système, compiler du C embarqué. Elle implique aussi que l’ajout d’une dépendance équivaut à accepter d’exécuter du code arbitraire fourni par un tiers, avec vos droits, sur votre machine, avant même que quoi que ce soit ne soit compilé.

Retournons le scénario. Sur un poste de développement, que trouve un script hostile ? Des clés SSH. Des jetons d’accès aux dépôts. Des identifiants cloud dans un fichier de configuration. Des variables d’environnement d’intégration continue. Sur un runner de CI, c’est pire encore : les secrets y sont injectés délibérément, souvent avec des droits d’écriture sur les registres de paquets — ce qui permet à l’attaque de se propager.

Ce graphique résume l’essentiel de mon changement d’avis. Toutes nos procédures d’analyse portaient sur l’artefact livré. Aucune ne portait sur ce qui s’était exécuté pour le produire.

Notre avis d’expert n° 1 : le chiffre de 245 millions est une distraction

Le nombre de téléchargements cumulés est le chiffre le plus repris et le moins utile. Il agrège des années d’installations automatiques, de miroirs, de robots d’intégration continue qui retéléchargent la même version mille fois par semaine. Il ne dit rien de votre exposition.

Ce qui détermine votre exposition, c’est l’intersection de deux ensembles : les versions exactes que votre projet a résolues, et la fenêtre temporelle pendant laquelle les versions piégées étaient disponibles. En dehors de cette intersection, vous ne risquez rien, quel que soit le nombre de téléchargements mondiaux.

C’est pour ça que mes neuf heures ont commencé par une commande ennuyeuse : rassembler tous les Cargo.lock de l’organisation, y compris ceux des dépôts d’exemples et des outils internes que personne ne considère comme « du vrai code ». Sur onze dépôts, deux avaient une résolution transitive vers un paquet listé. Aucun des deux ne le mentionnait dans son Cargo.toml.

Notre avis d’expert n° 2 : ce n’est pas un problème de Rust

Chaque incident de ce genre déclenche la même réaction tribale : ceux qui n’aiment pas le langage concerné y voient une confirmation, ceux qui l’aiment minimisent. Les deux ont tort, et l’écosystème Rust est en réalité l’un des mieux outillés pour répondre.

Le mécanisme visé — exécution de code à l’installation ou à la compilation d’une dépendance — existe presque partout. Les scripts de post-installation npm sont le cas d’école. Les fichiers setup.py Python en sont un autre. Les plugins de build Gradle et Maven aussi. Le problème n’est pas linguistique, il est architectural : nous avons construit des chaînes de production où installer et exécuter sont devenus la même action.

La conséquence pratique est libératrice : les réflexes ci-dessous sont transposables tels quels à vos projets Node, Python ou Java. Ne construisez pas une réponse spécifique à Rust, vous la referiez dans six mois pour un autre écosystème.

Notre avis d’expert n° 3 : votre CI est la vraie cible, et elle est mal défendue

Voici le constat qui m’a le plus dérangée pendant l’audit. Nos runners d’intégration continue sont, de très loin, l’environnement le plus riche en secrets de toute l’organisation — et le moins surveillé. Ils ont accès au registre de paquets, au registre de conteneurs, souvent à des identifiants de déploiement. Ils exécutent, à chaque commit, du code fourni par des centaines de tiers. Et ils n’ont, dans la plupart des équipes, aucune restriction de sortie réseau.

Un script de compilation hostile qui trouve un jeton de publication et l’exfiltre vers un serveur distant boucle la propagation : le paquet suivant qu’il empoisonnera sera le vôtre, signé par vous, distribué à vos utilisateurs. C’est le scénario qui transforme un incident isolé en cascade.

La contre-mesure la plus rentable n’est pas la plus sophistiquée : restreindre les destinations réseau autorisées pendant la phase de compilation. Un build légitime a besoin de joindre le registre de paquets et éventuellement un miroir. Il n’a aucune raison de contacter une adresse arbitraire. Cette seule règle neutralise l’exfiltration, quelle que soit l’ingéniosité du script.

C’est aussi le genre de durcissement que les équipes cyber recommandent depuis des années sans être écoutées ; nos confrères de WebGuard Agency font le même constat sur les chaînes de secrets CI/CD, où l’absence de filtrage sortant reste l’angle mort le plus fréquent en PME.

Les 4 réflexes que j’ai gardés après 9 heures d’audit

Réflexe 1 — le fichier de verrouillage est la source de vérité. Cherchez dans tous les Cargo.lock, y compris ceux des dépôts que vous considérez comme secondaires. Les dépendances transitives sont invisibles ailleurs.

Réflexe 2 — recensez ce qui s’exécute à la compilation. Sur nos deux dépôts principaux, sur environ 400 dépendances transitives, une quarantaine fournissaient un script de compilation. C’est ça, votre vraie surface d’attaque : quarante, pas quatre cents. Ce nombre est petit, il est auditable, et personne ne le connaissait avant que je le calcule.

Réflexe 3 — cloisonnez la compilation. Filtrage réseau sortant, exécution en conteneur jetable, aucun secret de production monté pendant la phase de build. Cette mesure protège aussi contre la prochaine attaque, dont vous ne connaissez pas encore le nom.

Réflexe 4 — la rotation des secrets est le vrai coût. Nous avons fait tourner tous les jetons présents sur les runners depuis juin. C’est fastidieux, cela casse des choses, et c’était la seule action qui répondait à la question « et si nous avions été touchés sans le savoir ». La difficulté de cette rotation est en soi un indicateur de dette : si faire tourner un secret prend deux jours, c’est déjà un problème indépendamment de tout incident.

Ce que ça dit de notre rapport aux dépendances

Il y a une tentation, après un épisode pareil, de basculer dans l’austérité : réduire le nombre de dépendances, tout réécrire, revenir à la bibliothèque standard. C’est une réaction compréhensible et généralement contre-productive. Le code que vous écrivez vous-même n’est pas magiquement plus sûr ; il est simplement moins audité par des tiers.

La question utile n’est pas le nombre de dépendances mais leur privilège. Combien d’entre elles exécutent du code chez vous avant que vous ne l’ayez demandé ? Combien accèdent au réseau pendant le build ? Combien seriez-vous capable de remplacer en une journée ? Ces trois questions sont mesurables, elles produisent des chiffres, et ces chiffres se réduisent.

Si vous mettez en place une chaîne de compilation propre à cette occasion, notre guide sur la compilation de Rust vers WebAssembly détaille l’isolation de la chaîne d’outils, et notre parcours Comment créer une plateforme SaaS multi-tenant applique la même logique de cloisonnement aux dépendances Python, où les scripts d’installation posent exactement le même problème.

Enfin, pour les équipes qui exploitent des modèles en production et se demandent où placer la frontière de confiance, l’analyse de Plug-Tech sur la sécurité des déploiements IA arrive à une conclusion troublante de similarité : le composant le plus dangereux est toujours celui que personne ne s’attribue.

Questions fréquentes