Autrefois, on reconnaissait facilement un développeur. Ils avaient le terminal noir et vert, l'éditeur avec dix-sept fichiers ouverts, et une capacité étrange à quitter vim (`esc :q!` si vous ne saviez pas). Écrire des logiciels exigeait un niveau élevé, et ce niveau écartait la plupart des gens.
Ouvrez quelque chose comme Claude Cowork, tapez « construis-moi un outil qui nettoie cette feuille de calcul et m'envoie un résumé tous les lundis », puis partez. Quelques minutes plus tard, il y a un résultat fonctionnel. Derrière la fenêtre de chat, un agent a lancé une machine virtuelle, écrit du vrai code, importé toutes les bibliothèques dont il a décidé avoir besoin, l'a exécuté, a rencontré une erreur, l'a corrigée et vous a remis le résultat. Vous avez décrit un résultat, tandis qu'une machine s'est occupée de l'ingénierie.
Félicitations ! Vous êtes maintenant un développeur, un qui n'a jamais vu une seule ligne de ce qui a été construit.
La dépendance que vous n'avez pas choisie
Pour résoudre votre problème, votre agent se tourne vers une bibliothèque publique de packages et télécharge le code d'inconnus sur une machine. C'est ainsi que fonctionne le logiciel moderne, et les développeurs le font constamment. La différence est que ces développeurs savent au moins que `npm install` est en cours d'exécution et connaissent les risques encourus. Vous, peut-être pas. Vous avez demandé un nettoyeur de feuille de calcul.
Et cette bibliothèque est sous attaque active. Ce mois-ci, un attaquant a republié 141 packages dans l'écosystème populaire d'agents IA @mastra en une rafale de 45 minutes pendant la nuit, glissant une dépendance malveillante dans chacun d'eux. Le package empoisonné, un sosie d'une bibliothèque de dates courante, a exécuté un script au moment de l'installation qui a téléchargé une seconde charge utile, l'a lancée comme un processus d'arrière-plan invisible, puis s'est supprimé pour masquer les preuves. La charge utile a fouillé plus de 160 portefeuilles crypto de navigateurs et s'est installée pour une persistance sur Mac, Windows et Linux. Un package central affecté est téléchargé près d'un million de fois par semaine.
Lorsqu'un développeur ajoute une dépendance, il y a généralement un certain jugement impliqué. S'il n'est pas déjà familier avec les outils populaires ou fiables du domaine, il peut jeter un œil aux nombres de téléchargements, au dernier commit et à qui le maintient. Ensuite, la décision est soumise dans une pull request où quelqu'un d'autre peut interroger et examiner le package avant qu'il ne soit merge. La manière dont une IA choisit un package n'est pas claire. Parfois, c'est simplement ce qui est le plus courant, ou parfois c'est vraiment obscur. Mais les IA hallucinent aussi des packages qui semblent réels mais ne le sont pas. Lorsque ce dernier cas se produit, dans le meilleur des cas, le package inventé par l'IA n'existe pas. Dans le pire des cas, un attaquant a deviné ce qu'une IA pourrait inventer et a placé un malware dangereux sous ce nom de package. C'est ce qu'on appelle le slopsquatting, et c'est quelque chose que toute personne utilisant l'IA pour coder doit surveiller.
.png)
Ce n'est pas un argument « n'utilisez pas les outils »
Les outils sont transformateurs, et ils ne vont pas retourner dans leur boîte. Le sandboxing aide, une VM isolée contient un certain rayon d'explosion, et c'est réel. Mais le code dans les sandboxes est livré à de vrais dépôts et de vrais identifiants dès qu'il est utile, et l'isolation ne résout pas le fait que vous n'avez jamais examiné les dépendances.
Les LLM ont donné le clavier à tout le monde, ce qui est merveilleux. Mais ce faisant, nous avons déplacé la décision la plus dangereuse en matière de logiciel (quel code puis-je suffisamment faire confiance pour exécuter ?) vers un endroit où aucun humain ne regarde. La réponse n'est pas de relire chaque diff. Ce train est passé. Au lieu de cela, nous devons pousser la vérification de confiance là où l'installation a lieu. Bloquez les packages malveillants connus avant qu'ils n'atteignent la machine, rendez les scripts d'installation opt-in plutôt qu'automatiques, et traitez « l'agent s'en est occupé » comme une phrase qui devrait vous rendre légèrement nerveux.
Tout le monde est développeur maintenant. Le vélo n'a pas de petites roues, et la plupart des nouveaux cyclistes ont les deux mains lâchées du guidon.
Regarde, Maman, pas de garde-fous ! La bonne nouvelle est que vous pouvez les rajouter sans ralentir personne. Aikido Device Protection intercepte le mauvais package au seul moment qui compte, avant son installation, de sorte que « l'agent s'en est occupé » cesse d'être une phrase qui devrait vous effrayer.
Si vous voulez savoir comment sécuriser vos applications « vibe-coded », consultez notre Vibe Coding Checklist for Security.
