Les postes de travail des développeurs sont devenus la cible au ROI le plus élevé dans les attaques de la chaîne d'approvisionnement logicielle, et le problème s'accélère.
« Une métrique clé me préoccupe : au cours des trois derniers mois, nous avons eu sept fois plus de vulnérabilités dans notre chaîne d'approvisionnement par rapport aux trois mois précédents, » déclare Gavin Williams, Responsable Ingénierie chez Omnea, fournisseur de plateforme d'approvisionnement basée sur l'IA.
« Nous constatons de plus en plus de problèmes et de soucis au sein des registres au fil du temps, avec davantage d'attaques de la chaîne d'approvisionnement, mais aussi plus de problèmes détectés par les outils d'IA. Il est si facile pour les développeurs d'installer un package vulnérable ou quelque chose qui a été compromis. »
L'industrie a passé des années à déplacer la sécurité vers la gauche dans le pipeline. Mais la surface d'attaque elle-même s'est déplacée encore plus à gauche que le pipeline, et sur les machines elles-mêmes.
Au cours de la seule année dernière, les attaquants sont tous passés par différentes portes : la récente violation de GitHub via une extension VS Code malveillante, Trivy via un outil de sécurité, TanStack (mini Shai-Hulud) via un gestionnaire de paquets, les attaques TeamPCP via des paquets malveillants, mais ils partagent tous un facteur clé. Ils ciblent l'appareil du développeur. Et cela fonctionne.
Mais pourquoi ?
J'aime l'imaginer ainsi : la plupart des bâtiments commerciaux ont leur porte d'entrée solidement verrouillée avec des serrures, des caméras, etc. Mais il y a aussi une entrée pour le personnel à l'arrière, avec une porte coupe-feu maintenue ouverte, car des personnes vont et viennent toute la journée avec des livraisons. Cette entrée du personnel mène directement au bureau qui détient les clés de toutes les pièces, ce qui est en fait le poste de travail du développeur.
Jusqu'à présent, les organisations et leurs équipes de sécurité n'ont pas considéré cela comme un risque de sécurité, parce que « c'est juste pour eux ». C'est une sorte de croyance aveugle que personne ne s'en souciera parce que ce n'est pas pour eux.
Mais si vous êtes un attaquant, peu importe à qui est destinée la porte (ou, dans ce cas, l'appareil), il est logique d'aller là où la friction est la plus faible.
L'écart entre ce que les EDR voient et ce que les développeurs installent réellement
L'une des principales raisons des attaques de la chaîne d’approvisionnement, selon James Berthoty, fondateur et analyste chez Latio, est que les endpoints des développeurs restent largement non surveillés, car les outils de détection et de gestion traditionnels ne sont pas adaptés à leurs cas d'usage.
« Les outils EDR ne sont pas granulaires, ils se concentrent principalement sur les applications ou programmes installés plutôt que sur les paquets internes de cette application autorisée », déclare Walid Mahmoud, responsable DevSecOps dans le secteur public britannique.
Les EDR surveillent l'activité malveillante au niveau de l'application. Mais les organisations ne peuvent pas voir ce qui se passe à l'intérieur des outils que les développeurs utilisent quotidiennement, comme les paquets npm, les extensions d'IDE, les plugins Chrome, les compétences Cursor.
C'est important, car le problème commence avant même qu'une seule ligne de code ne soit écrite.
« Il ne s'agit pas de personnes déployant du code non sécurisé en production. Il s'agit plutôt d'une exposition des identifiants GitHub dès l'installation », déclare Gavin d'Omnea.
Par exemple, un paquet malveillant peut exécuter un script post-installation et exfiltrer des identifiants dès qu'un développeur l'installe.
Et bien sûr, il serait impardonnable de ne pas mentionner la facilité déconcertante avec laquelle il est désormais possible de créer des malwares grâce aux LLM. Steeven George, responsable de la sécurité des produits chez Raisin, affirme que c'était un domaine qui créait un « angle mort » pour son organisation, et il n'est pas le seul.
Walid, du secteur public britannique, explique l'impact de l'introduction de l'IA : « Beaucoup de gens vivent désormais dans le terminal et installent de nombreux fichiers markdown et autres éléments. Cependant, naturellement, sans aucun processus vérifié, rien ne les empêche de télécharger des choses qu'ils ont vues sur Reddit ou X. Celles-ci pourraient faire partie d'une campagne de malwares visant à inciter les gens à les télécharger. Et ensuite, le reste appartient à l'histoire. »
Une partie du problème est qu'aucune équipe unique ne gère l'intersection où se trouvent les machines des développeurs, là où l'AppSec, la sécurité des endpoints, l'identité et le risque lié à la chaîne d’approvisionnement convergent. Il a donc été plus facile d'utiliser des outils comme les EDR et les MDM pour combler le vide sans réellement protéger les organisations contre ces menaces croissantes. Mais il devient clair que ce n'est plus viable. L'inconvénient est de subir une attaque majeure de la chaîne d’approvisionnement (C'est un inconvénient de taille).
Comment les équipes sécurisent les machines des développeurs contre les attaques de la chaîne d’approvisionnement
Chris Holman, responsable d'équipe ingénieurs DevSecOps chez la firme de cybersécurité Glasswall, a déployé Aikido Safe Chain sur l'ensemble de l'infrastructure de l'entreprise.
« Tout pipeline de production qui touche des paquets supportés est désormais scanné avec Safe Chain pour s'assurer que nous n'installons rien de corrompu. »
Walid a fait de même au sein du département du secteur public britannique.
« Cela a ajouté une porte de contrôle que nous avons normalement dans notre cycle de vie de développement logiciel, mais cette porte de contrôle est désormais locale. Nous avons donc un peu plus confiance que les développeurs disposent d'une sorte de garde-fou sur leur machine locale qui les interrogera avant d'installer quelque chose. »
Mais les paquets ne sont qu'un point d'entrée ; l'équipe de Gavin utilisait déjà Safe Chain lorsqu'il a déclaré qu'ils avaient réalisé qu'ils avaient besoin d'une visibilité plus large sur l'ensemble de l'appareil du développeur.
« Nous utilisions Safe Chain jusqu'à présent, mais disposer d'un moyen plus complet de gérer l'ensemble des appareils de chacun et de vérifier réellement que les choses ne sont pas installées de manière non sécurisée va changer la donne », a déclaré Gavin.
C'est ce qui a conduit plusieurs de ces équipes vers Aikido Device Protection, qui étend le même principe au-delà des registres de paquets aux extensions d'IDE, aux plugins de navigateur et aux outils d'IA.
Walid le décrit comme une « version améliorée de Safe Chain ». Il ajoute : « Cela nous fournit la télémétrie nécessaire pour savoir ce que les développeurs utilisent ou ce qu'ils ont tenté d'installer, nous donnant ainsi plus de contexte sur qui est susceptible d'être victime 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 ce type de couverture. Les outils EDR ne présentent pas les paquets installés sur les machines des développeurs, et les vulnérabilités dans les extensions Chrome ne sont pas couvertes par d'autres fournisseurs. Nous allons certainement combler cette lacune. »
Steeven l'a déjà testé. « Je suis vraiment ravi de voir l'aperçu complet des extensions de navigateur, des extensions Cursor et de tous les registres de packages. Cela nous donne un modèle de menace global pour toutes nos machines de développeurs. »
Chaque équipe à laquelle nous avons parlé a identifié la même lacune
Le schéma de ces conversations était cohérent : des responsables de la sécurité et de l'ingénierie, au sein de différentes entreprises et industries, ont tous identifié indépendamment la même lacune. Les machines de développeurs se trouvent entre les mailles des outils existants, et les attaquants l'ont bien compris.
Les équipes qui s'y sont déjà attelées ont commencé par des contrôles au niveau des packages et étendent désormais leur visibilité à l'ensemble des appareils. Celles qui n'ont pas encore commencé utilisent probablement la même configuration EDR et MDM qui a manqué toutes les attaques mentionnées dans cet article.
Découvrez comment fonctionne la protection des appareils ici ou essayez-la ici.
