Les postes de travail des développeurs sont désormais la cible offrant le meilleur retour sur investissement dans attaques de la chaîne d’approvisionnement logicielle, et le problème ne cesse de s’aggraver.
« Il y a un indicateur clé qui m'inquiète : au cours des trois derniers mois, nous avons recensé sept fois plus de vulnérabilités dans notre chaîne d'approvisionnement qu'au cours des trois mois précédents », explique Gavin Williams, responsable de l'ingénierie chez Omnea, fournisseur d'une plateforme d'approvisionnement basée sur l'IA.
« Nous constatons de plus en plus de problèmes et de failles dans les registres au fil du temps, avec une recrudescence attaques de la chaîne d’approvisionnement aussi un nombre croissant de failles détectées par les outils d’IA. Il est tellement facile pour les développeurs d’installer un paquet vulnérable ou un élément qui a été compromis. »
Le secteur s'efforce depuis des années d'intégrer la sécurité dès les premières étapes du processus. Mais la surface d'attaque elle-même s'est déplacée encore plus en amont que le processus, pour s'étendre jusqu'aux machines elles-mêmes.
Rien que l'année dernière, les pirates ont tous utilisé des voies d'accès différentes : la récente faille de GitHub via une extension malveillante de VS Code, Trivy un outil de sécurité, TanStack (mini Shai-Hulud) via un gestionnaire de paquets, les attaques TeamPCP via des paquets malveillants, mais elles ont toutes un point commun. Elles ciblent l'appareil des développeurs. Et ça marche.
Mais pourquoi ?
J'aime voir les choses ainsi : la plupart des immeubles commerciaux ont leur entrée principale sécurisée par des serrures, des caméras et autres dispositifs similaires. Mais il y a aussi une entrée de service à l'arrière, dont la porte coupe-feu est maintenue ouverte, car les livreurs vont et viennent toute la journée. Cette entrée de service mène directement au bureau où se trouvent les clés de toutes les pièces, ce qui correspond en fait au poste de travail du développeur.
Jusqu’à présent, les entreprises et leurs équipes de sécurité n’ont pas considéré cela comme un risque pour la sécurité, car « cela ne les concerne pas directement ». C’est une sorte de conviction aveugle selon laquelle personne ne s’en prendra à eux, puisque cela ne les concerne pas.
Mais si vous êtes un pirate, peu importe à qui s'adresse la porte (ou, dans ce cas précis, l'appareil) : il est logique de s'attaquer là où la résistance est la plus faible.
L'écart entre ce que détecte l'EDR et ce que les développeurs installent réellement
Selon James Berthoty, fondateur et analyste chez Latio, l’une des principales causes des attaques de la chaîne d’approvisionnement réside dans le fait que les terminaux des développeurs ne font généralement l’objet d’aucune surveillance, les outils traditionnels de détection et de gestion ne s’adaptant pas bien à leurs cas d’utilisation.
« Les outils EDR ne sont pas suffisamment précis ; ils se concentrent principalement sur les applications ou les programmes installés plutôt que sur les composants internes de ces applications autorisées », explique Walid Mahmoud, DevSecOps dans le secteur public britannique.
Les solutions EDR surveillent les activités malveillantes au niveau des applications. Cependant, les entreprises ne sont pas en mesure de voir ce qui se passe au sein des outils que les développeurs utilisent quotidiennement, tels que les paquets npm, les extensions d'IDE, les extensions Chrome ou les fonctionnalités de Cursor.
C'est important, car le problème commence avant même qu'une seule ligne de code ne soit écrite.
« Le problème n’est pas que les gens déploient du code non sécurisé en production. Le problème, c’est que dès l’installation, leurs identifiants GitHub sont exposés », explique Gavin, d’Omnea.
Par exemple, un paquet malveillant peut exécuter un script post-installation et dérober des identifiants dès qu'un développeur l'installe.
Et bien sûr, il serait dommage de ne pas mentionner à quel point il devient facile de créer des logiciels malveillants grâce aux modèles de langage (LLM). Steeven George, responsable de la sécurité des produits chez Raisin, explique que ce domaine constituait un « angle mort » pour son entreprise, et il n'est pas le seul dans ce cas.
Walid, qui travaille dans le secteur public britannique, explique les conséquences de l'introduction de l'IA : « Beaucoup de gens utilisent désormais le terminal et y installent de nombreux fichiers Markdown et autres éléments. Cependant, en l'absence de processus de vérification, rien ne les empêche de télécharger des fichiers qu'ils ont vus sur Reddit ou X. Ceux-ci pourraient faire partie d'une campagne de logiciels malveillants visant à inciter les utilisateurs à les télécharger. Et ensuite... on connaît la suite. »
Une partie du problème réside dans le fait qu’aucune équipe ne se charge spécifiquement de ce point de convergence où se trouvent les machines des développeurs, là où se rejoignent AppSec, la sécurité des terminaux, la gestion des identités et les risques liés à la chaîne d’approvisionnement. Il a donc été plus facile d’utiliser des outils tels que l’EDR et le MDM pour combler ce vide sans réellement protéger les organisations contre ces menaces croissantes. Mais il devient évident que cette approche n’est plus viable. Le revers de la médaille, c’est d’être la cible d’une attaque majeure visant la chaîne d’approvisionnement (ce qui n’est pas une mince affaire).
Comment les équipes protègent les machines des développeurs contre attaques de la chaîne d’approvisionnement
Chris Holman, chef d'équipe DevSecOps chez Glasswall, une entreprise spécialisée dans la cybersécurité, a déployé Aikido Chain sur l'ensemble de l'infrastructure de l'entreprise.
« Tout pipeline de production traitant des paquets pris en charge est désormais analysé par Safe Chain afin de s'assurer que nous n'installons aucun élément malveillant. »
Walid a fait de même dans l'ensemble du secteur public britannique.
« Cela a ajouté une étape de contrôle que nous avons habituellement dans notre cycle de vie de développement logiciel, mais cette étape est désormais locale. Nous sommes donc un peu plus rassurés de savoir que les développeurs disposent d'une sorte de garde-fou sur leur machine locale qui leur posera des questions avant qu'ils n'installent quoi que ce soit. »
Mais les paquets ne constituent qu'un point d'entrée parmi d'autres ; l'équipe de Gavin utilisait déjà Safe Chain lorsqu'elle s'est rendu compte qu'elle avait besoin d'une visibilité plus large sur l'ensemble de l'environnement de développement.
« Jusqu’à présent, nous utilisions Safe Chain, mais disposer d’un moyen plus complet de gérer tous les appareils et de vérifier réellement qu’aucune application n’est installée de manière non sécurisée va véritablement changer la donne », a déclaré Gavin.
C'est ce qui a conduit plusieurs de ces équipes à adopter la solution « Device Protection »Aikido, qui étend ce même principe au-delà des registres de paquets pour couvrir les extensions d'IDE, les plugins de navigateur et les outils d'IA.
Walid la décrit comme une « version améliorée de Safe Chain ». Il explique : « Elle nous fournit les données nécessaires pour savoir ce que les développeurs utilisent ou ce qu’ils ont tenté d’installer, ce qui nous donne davantage d’informations sur les personnes susceptibles d’être la cible d’une attaque ».
L'équipe de Kristina chez Cognism prévoit de le déployer pour des raisons similaires. « Aucun autre outil n'offre actuellement une telle couverture. Les outils EDR ne répertorient pas les paquets installés sur les machines des développeurs, et les vulnérabilités des extensions Chrome ne sont pas couvertes par les autres fournisseurs. Nous allons sans aucun doute combler cette lacune. »
Steeven l'a déjà testé. « Je suis vraiment ravi de disposer d'une vue d'ensemble complète des extensions de navigateur, des extensions Cursor et de tous les registres de paquets. Cela nous offre une vision globale des menaces pour l'ensemble de nos machines de développement. »
Toutes les équipes avec lesquelles nous avons discuté ont constaté le même manque
Un schéma récurrent se dégageait de ces discussions : les responsables de la sécurité et de l'ingénierie de différentes entreprises, issues de divers secteurs, ont tous, indépendamment les uns des autres, mis en évidence la même lacune. Les machines des développeurs se retrouvent dans les mailles du filet des outils existants, et les pirates l'ont bien compris.
Les équipes qui se sont déjà attelées à cette tâche ont commencé par mettre en place des contrôles au niveau des paquets et s'orientent désormais vers une visibilité complète sur les appareils. Celles qui n'ont pas encore commencé utilisent probablement la même configuration EDR et MDM qui n'a détecté aucune des attaques mentionnées dans cet article.
Découvrez ici comment fonctionne la protection des appareils ou testez-la ici.
