Le code malveillant entre dans vos logiciels par la chaîne d’approvisionnement

Une attaque de la chaîne d’approvisionnement ne force pas l’entrée du logiciel que vous utilisez. Elle empoisonne l’une des pièces dont ce logiciel est fait, puis attend que le processus de mise à jour habituel la dépose sur votre machine. L’application s’installe proprement, la signature reste valide et la mise à jour arrive par le canal officiel. Le code malveillant voyage avec elle. C’est cette inversion qui rend la technique si efficace : elle transforme la confiance qui fait tourner le logiciel en la faille que l’on exploite.

Presque rien de ce que vous exécutez aujourd’hui n’est entièrement écrit par l’entreprise dont le nom s’affiche. Une seule application peut entraîner des centaines ou des milliers de paquets open source, chacun maintenu par des inconnus, chacun en tirant d’autres derrière lui. Les développeurs lisent rarement ce code ; ils font confiance au registre d’où il provient et au numéro de version qui l’accompagne. Quiconque se glisse dans un maillon de cette chaîne atteint d’un coup tous ceux qui se trouvent en aval, et c’est pourquoi une seule pièce empoisonnée peut toucher des dizaines de milliers de projets avant que quelqu’un ne s’en aperçoive.

Les points d’entrée se regroupent en quelques schémas. Le typosquatting place un paquet malveillant dont le nom n’est qu’à une touche du nom populaire, et attend la faute de frappe. La confusion de dépendances exploite la façon dont les outils résolvent les noms et les pousse à récupérer un paquet public plutôt que le paquet privé de l’entreprise. Le détournement de compte s’empare des identifiants d’un vrai mainteneur et diffuse le maliciel comme une simple mise à jour ; début 2026, le paquet très répandu axios a brièvement publié une version compromise après que la machine de son mainteneur principal eut été piratée par ingénierie sociale. Enfin, l’empoisonnement de la chaîne de production vise les systèmes automatiques qui assemblent et publient le logiciel, où une seule étape corrompue atteint tous les projets qui en dépendent.

La chaîne de production est devenue la cible la plus convoitée précisément parce qu’elle se situe en amont de tout le reste. Lorsque le composant populaire de GitHub Actions tj-actions/changed-files a été compromis en 2025, les attaquants ont réécrit ses étiquettes de version pour pointer vers du code malveillant et ont extrait des secrets des journaux de compilation de plus de vingt mille dépôts : clés d’accès, jetons et clés privées, le tout en clair. Une campagne ultérieure, baptisée Megalodon par les chercheurs, a transformé GitHub Actions en une porte dérobée capable de se propager seule et qui a atteint 5 561 dépôts en environ six heures. La machine qui construit votre logiciel peut être détournée aussi facilement que le logiciel lui-même.

Les outils que les développeurs utilisent chaque jour sont eux aussi dans la zone d’impact. GlassWorm, repéré pour la première fois fin 2025, s’est répandu par des extensions de Visual Studio Code sur les places de marché OpenVSX et Microsoft. Il dissimulait sa charge avec des caractères Unicode invisibles, si bien que les lignes malveillantes étaient littéralement illisibles dans l’éditeur et échappaient à la relecture humaine. Une fois installé, il volait les identifiants npm, GitHub et Git, puis s’en servait pour infecter automatiquement d’autres paquets et extensions, le trait qui définit un ver. Comme les éditeurs mettent les extensions à jour en silence en arrière-plan, les victimes recevaient les versions empoisonnées sans rien cliquer. Une autre extension VS Code empoisonnée a servi à voler près de 3 800 dépôts internes de GitHub lui-même.

Ce qui rend ces attaques si difficiles à saisir, c’est que chaque étape, prise isolément, paraît légitime. Le paquet est signé. La mise à jour vient du vrai registre. Le compte du mainteneur est authentique. Les défenses classiques cherchent des fichiers connus comme nuisibles et des maliciels évidents, mais les attaques de la chaîne d’approvisionnement se cachent dans du code de confiance, attendu et souvent invisible, qui arrive exactement quand et comme le logiciel est censé arriver. Pire : le conseil de sécurité de toujours, mettre à jour sans attendre, est précisément le mécanisme dont dépend l’attaquant. Pour la première fois, installer la dernière version n’est pas, sans nuance, le choix sûr.

Les défenseurs se sont accordés sur une poignée de pratiques qui marchent. Les fichiers de verrouillage figent chaque dépendance à une version exacte et vérifiée, de sorte que l’installateur ne récupère que ce qui a été relu, et non le plus récent. Désactiver les scripts d’installation automatiques coupe la voie la plus courante par laquelle un paquet malveillant exécute du code dès qu’il arrive. Épingler les GitHub Actions à un hachage de commit précis, plutôt qu’à une étiquette mobile, neutralise l’astuce de réécriture des étiquettes. Une nomenclature logicielle, la liste détaillée de chaque composant d’une compilation, permet à une équipe de savoir en quelques minutes si elle est exposée quand le prochain incident est révélé. Beaucoup des organisations qui ont échappé aux attaques récentes n’ont rien fait d’exotique : elles compilaient à partir d’un fichier de verrouillage validé et travaillaient derrière un proxy de registre qui mettait en quarantaine les paquets fraîchement publiés.

Pour ceux qui n’écrivent pas de code, la protection est surtout indirecte, mais la leçon ne l’est pas. La chaîne d’approvisionnement logicielle est désormais un champ de bataille de premier plan, et ce sont les entreprises qui fabriquent les applications de votre téléphone et de votre ordinateur portable qui doivent la sécuriser. La réponse raisonnable n’est ni la panique ni le vieux réflexe de tout mettre à jour dès qu’une notification apparaît. C’est de préférer les logiciels d’équipes qui publient ce qu’elles livrent et comment elles le construisent, et de traiter la notion de source de confiance comme quelque chose qui se mérite à chaque maillon, et non comme une propriété qui descend toute seule la chaîne.

La réponse du secteur se dessine autour de la provenance : une preuve cryptographique de l’origine d’un bout de code et de la manière dont il a été construit, vérifiée automatiquement avant toute installation. C’est la même idée qui a sécurisé le trafic web il y a une génération, appliquée cette fois à la chaîne de montage du logiciel lui-même. Tant que cette preuve n’est pas universelle, chaque installation reste un acte de confiance envers des gens que vous ne rencontrerez jamais.