Des versions malveillantes de Nx et de certains plugins pris en charge ont été diffusées

• Des versions malveillantes des packages et plugins Nx ont été publiées sur npm, ont scanné le système de fichiers, collecté des identifiants, puis les ont envoyés vers un dépôt du compte Github de l’utilisateur
• Pour vérifier si vous êtes concerné, il faut confirmer si un dépôt s1ngularity-repository a été créé sur votre compte Github
• En cas d’infection, il est impératif de remplacer les tokens et mots de passe, supprimer le dépôt malveillant et vérifier les fichiers de configuration du shell
• Les versions malveillantes affectaient le système via un script postinstall ; le risque d’exécution involontaire augmentait notamment lors de l’utilisation du plugin VSCode Nx Console
• L’équipe Nx a mis en place des mesures supplémentaires de sécurité et de prévention de récidive, et les versions concernées ont été supprimées de npm

---

Vue d’ensemble et résumé

• Cette alerte de sécurité concerne une grave attaque de la chaîne d’approvisionnement visant les packages Nx et certains plugins associés, avec diffusion de code malveillant via npm
• Les versions malveillantes scannaient le système de fichiers des utilisateurs pour collecter des informations d’authentification, des chemins et d’autres données, puis les téléversaient vers un dépôt Github (s1ngularity-repository)
• Le script postinstall malveillant modifiait également les fichiers de configuration du shell de l’utilisateur (.zshrc, .bashrc) pour y ajouter une commande d’arrêt du système
• Le vecteur d’attaque, le déroulement de l’attaque, les versions affectées, les actions immédiates à entreprendre et les mesures de prévention sont détaillés

Mesures d’urgence

Vérifications que tout le monde doit effectuer

1. Vérifier dans la liste des dépôts de votre compte Github si s1ngularity-repository a été créé
2. Télécharger les fichiers contenus dans ce dépôt afin de les conserver comme archive
3. Supprimer le dépôt de Github
4. Envoyer un e-mail à [e-mail] pour recevoir les instructions de déchiffrement des informations compromises
5. Remplacer immédiatement tous les identifiants et tokens de tous les comptes

Comment remplacer le token Github

• Se rendre sur https://github.com/settings/connections/…
• Révoquer les autorisations de l’application connectée afin d’invalider le token existant
• Si vous utilisez la CLI gh, vous réauthentifier pour générer un nouveau token
• Sans action de votre part, l’ancien token risque d’être exploité

Cesser d’utiliser les versions malveillantes de Nx et nettoyer l’environnement

• Vérifier si la version de Nx actuellement utilisée fait partie des versions malveillantes avec la commande npm ls nx
• Si c’est une version infectée, mettre à jour avec npm uninstall nx && npm install nx@latest
• Nettoyer le cache avec npm cache clean --force

Utilisateurs déjà infectés

• Remplacer les tokens npm et Github
• Réinitialiser tous les mots de passe et identifiants de Github et des services associés
• Vérifier si des commandes inconnues ont été insérées dans les fichiers .zshrc et .bashrc, puis les supprimer

Si vous administrez un dépôt interne de packages

• Supprimer immédiatement les versions malveillantes du proxy dans le registry interne afin d’empêcher toute propagation supplémentaire

Versions affectées

Package Nx

• 21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, 20.12.0
• Supprimées de npm à 10:44 PM EDT

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

• Supprimés de npm aux horaires de 10:44 PM et 6:20 AM EDT

Détails du vecteur d’attaque

Cause du workflow vulnérable

• Une vulnérabilité permettant l’exécution de code arbitraire a été introduite dans un workflow Github Actions
• En insérant un certain code bash dans le titre d’une PR, il était possible de faire exécuter des commandes système par le workflow : une vulnérabilité de type Bash Injection
• Le déclencheur pull_request_target donnait des privilèges élevés (GITHUB_TOKEN, etc.), ce qui a facilité l’exploitation
• Jusqu’à sa suppression, le workflow vulnérable est resté présent sur une ancienne branche autre que main, ce qui a permis à l’attaquant d’exécuter le workflow via une PR malveillante et de dérober des secrets

Processus de vol du token npm

• Le workflow vulnérable a été utilisé pour déclencher publish.yml
• publish.yml stockait le token npm dans Github Secrets, et ce token a été transmis à un webhook externe pendant le processus
• L’attaquant a finalement utilisé ce token pour téléverser sur npm des versions malveillantes de Nx et de packages pris en charge

Comportement du package malveillant

Collecte d’informations, y compris d’identifiants, et publication dans un dépôt Github

• Lors de l’exécution du script postinstall du package Nx infecté, l’emplacement de divers fichiers texte et des informations d’identification étaient collectés
• Ces données étaient encodées en base64 puis téléversées dans un dépôt Github nommé s1ngularity-repository
• Même si le dépôt a depuis été supprimé, il a été public auparavant ; il faut donc considérer qu’une fuite d’informations a pu se produire

Altération des profils shell (.zshrc, .bashrc)

• postinstall insérait la commande sudo shutdown -h 0, pouvant provoquer l’arrêt du système à l’ouverture d’un terminal et exposer potentiellement le mot de passe

Différents scénarios dans lesquels postinstall peut s’exécuter

• Au-delà d’une exécution explicite de npm install/yarn/pnpm install, cela peut aussi se produire via des dépendances transitives, des extensions d’éditeur ou l’exécution de scripts

• En particulier, l’extension Nx Console pour VSCode (versions 18.6.30 à 18.65.1) installait automatiquement nx@latest au lancement de l’éditeur, ce qui pouvait déclencher l’exécution de postinstall

• Il faut garder à l’esprit que des modules NPM peuvent être installés à divers endroits, même sans intention explicite

• À partir de Nx Console 18.66.0, l’installation de latest nx a été supprimée

Chronologie de l’attaque et de la réponse

21 août

• 4:31 PM : fusion d’une PR contenant la vulnérabilité d’injection Bash
• 10:48 PM : publication sur X (anciennement Twitter) d’un message signalant la vulnérabilité

22 août

• Après-midi : enquête interne et rollback du workflow vulnérable (incomplet)
• Mise en place de CodeQL pour détecter à l’avenir des vulnérabilités similaires dans les PR

24 août

• Apparition d’un commit dans le fork de l’attaquant laissant penser à une fuite du token npm
• Création puis suppression d’une PR malveillante, avec exécution de publish.yml par cette PR

26 au 27 août (diffusion des versions malveillantes, réponse)

• Publication successive sur npm de nombreuses versions malveillantes de Nx et de plugins
• Signalements d’incidents à Github et à la communauté NPM
• 10:44 PM : mesures prises par NPM, dont la suppression de l’ensemble des versions concernées
• 11:57 PM : invalidation de tous les tokens de publication des packages liés à Nx
• 27 août : correctif de Nx Console, activation de la 2FA, migration vers le mode Trusted Publisher et autres mesures complémentaires

Mesures préventives et réponse ultérieure

• 2FA rendue obligatoire pour tous les mainteneurs de l’organisation nrwl
• Adoption du mécanisme Trusted Publisher. Déploiement via token npm interdit
• Les futurs packages seront publiés uniquement après vérification via 2FA et mécanismes de confiance
• Détection de risques supplémentaires, validation des PR et protections de branches appliquées par étapes

Enseignements et plan à venir

• Cet incident rappelle l’importance, au niveau local comme international, de la sécurité de la chaîne d’approvisionnement, des pipelines CI/CD et de la réduction des privilèges des workflows
• Après un réexamen interne, l’équipe prévoit de partager avec la communauté les enseignements tirés

Contact

• Contact possible via [e-mail]

Références et annexe

• Principales issues Github, chronologie et posts associés
• Exemple du script telemetry.js présent dans les packages infectés
• Ce script collecte les chemins des principaux fichiers texte du système de fichiers dans le but de constituer un inventaire

Résumé de conclusion

• Il est important d’appliquer les dernières mises à jour et correctifs de Nx et des plugins associés
• Le remplacement immédiat des principales informations d’authentification, notamment sur npm et Github, est recommandé
• Cet incident montre qu’une gestion insuffisante de la sécurité de la chaîne d’approvisionnement et des autorisations de workflow peut conduire à un accident majeur

[GN⁺]

Commentaire Hacker News

• Je voudrais rappeler régulièrement qu’il faut désactiver les scripts npm install

  • Par exemple avec cette commande :

      npm config set ignore-scripts true [--global]
    

  • Ce réglage peut s’appliquer facilement au niveau du projet ou globalement

  • De nos jours, il est rare qu’un paquet légitime ne fonctionne pas sans scripts, donc cela ne pose généralement pas de problème

  • Pour les paquets qui en ont absolument besoin, on peut s’en sortir en créant un script d’installation séparé et en l’exécutant manuellement dans le dossier concerné

  • Ce n’est pas une solution miracle contre les attaques de supply chain, mais cela a effectivement bloqué un grand nombre d’attaques passant par npm

  • Voir la documentation officielle de npm config pour plus d’informations

  • De mon côté, j’utilise aussi bubblewrap pour exécuter npm, pnpm, yarn et toutes les sessions qu’ils lancent en isolation du système

    • Mon code source n’existe que sous ~/code, et j’enregistre le script bash ci-dessous comme npm au début du PATH
    • Je relie aussi les autres gestionnaires de paquets en symlink/hardlink :

      #!/usr/bin/bash
      bin=$(basename "$0")
      exec bwrap \
        --bind ~/.cache/nodejs ~/.cache \
        --bind ~/code ~/code \
        --dev /dev \
        --die-with-parent \
        --disable-userns \
        --new-session \
        --proc /proc \
        --ro-bind /etc/ca-certificates /etc/ca-certificates \
        --ro-bind /etc/resolv.conf /etc/resolv.conf \
        --ro-bind /etc/ssl /etc/ssl \
        --ro-bind /usr /usr \
        --setenv PATH /usr/bin \
        --share-net \
        --symlink /tmp /var/tmp \
        --symlink /usr/bin /bin \
        --symlink /usr/bin /sbin \
        --symlink /usr/lib /lib \
        --symlink /usr/lib /lib64 \
        --tmpfs /tmp \
        --unshare-all \
        --unshare-user \
        "/usr/bin/$bin" "$@"
      

    • Ainsi, le gestionnaire de paquets n’a accès qu’à ~/code et à une lecture seule des bibliothèques système
    • bubblewrap est un outil stable, utilisé notamment par Steam et flatpak

  • Utiliser pnpm peut aussi être une option. Les versions récentes ignorent par défaut tous les scripts de cycle de vie, et il faut les autoriser individuellement sur liste blanche pour les exécuter

  • Chaque fois que j’entends ce conseil, je me pose la même question : en pratique, aucun développeur ne lit vraiment les dizaines ou centaines de milliers de lignes de code installées par npm

    • Le workflow de la plupart des développeurs ressemble à ceci
      1. git clone
      2. npm install (c’est là qu’un paquet malveillant peut être installé ; ignorer les scripts post-install ne fait que retarder un peu le problème)
      3. npm run (c’est là que le paquet malveillant s’exécute et compromet la machine)
    • Pour que ce conseil soit réellement utile, il faudrait surveiller/auditer l’ensemble de node_modules entre 2 et 3, et personne ne fait ça

  • J’exécute tous les outils basés sur npm dans un conteneur Docker, sans accès à autre chose que le répertoire courant

    • Cela réduit drastiquement la surface d’attaque
    • La méthode est décrite sur ce blog

  • Je me demande pourquoi ce type de conseil ne s’applique pas de la même manière à setup.py (Python) ou build.rs (Rust)

    • Est-ce parce que npm est souvent détourné pour distribuer aussi des logiciels complets, alors que les gestionnaires de paquets des autres langages servent surtout à gérer des bibliothèques ?
    • Voir la discussion associée ici

• Il faut vraiment instaurer une culture où l’on réfléchit à deux fois avant d’ajouter une nouvelle dépendance

  • Il y a eu énormément d’attaques de supply chain cette année

  • Cette semaine, je voulais ajouter à un projet Go une barre de progression avec 8 compteurs statistiques

  • J’ai regardé une bibliothèque, elle faisait plus de 3 000 lignes de code, alors j’ai demandé à un LLM de générer un petit bout d’UI et j’ai obtenu une solution en moins de 150 lignes

  • Cela fait exactement ce que je veux, sans dépendance, et c’est tellement simple que tout le monde peut le lire et l’améliorer facilement

  • La fonctionnalité consiste à effacer la sortie du terminal et la redessiner chaque seconde, avec prise en charge thread-safe

  • Implémentation et revue comprises, 25 minutes ont suffi

  • Si l’on n’a pas besoin de fonctions statistiques complexes, une trentaine de lignes peuvent suffire pour une barre de progression

  • À l’avenir, quand je me demanderai s’il faut ajouter une dépendance, faire moi-même sera probablement la meilleure option pour moi

  • Je n’ai pas les ressources pour surveiller toutes les mises à jour de paquets

  • Je suis d’accord avec ce point, et je me souviens m’être senti très mal à l’aise au début de la popularisation des « gestionnaires de paquets par langage »

    • Travaillant côté programmation système, j’ai observé pip, npm, etc. d’un peu loin
    • Puis en passant sur des projets Rust, voir Cargo télécharger depuis Internet des dizaines de dépendances non vérifiées avec une seule ligne de config m’a semblé risqué
    • Et c’est effectivement arrivé. Je ne pense pas que ce soit une bonne direction. (Même si je n’ai aucun espoir qu’on revienne en arrière : la sécurité informatique n’existe pas vraiment…)

  • Je pense qu’une approche comme cargo vet est la voie à suivre : présentation de cargo vet

    • Bien sûr, le coût en overhead est inévitable si tous les écosystèmes de langages doivent mettre en place ce genre de système
    • Les débuts d’Internet ou de l’e-mail ont eux aussi connu de belles périodes, avant d’être dégradés par le spam et la commercialisation
    • Désormais, même la chaîne des dépendances subit le même sort
    • C’est pour cela qu’on n’arrive pas à préserver durablement de bons environnements

  • La différence entre implémenter soi-même et utiliser une bibliothèque est évidente

    • Une bibliothèque est par nature généraliste et doit être flexible et configurable pour convenir à des environnements variés, ce qui explique qu’elle soit plus volumineuse

  • Je déteste vraiment ces bibliothèques de barre de progression, surtout quand elles cassent l’emacs shell (expo, eas, etc.)

    • Je ne comprends pas pourquoi elles n’affichent pas simplement quelque chose comme ..10%..20%..30% ou Uploading…
    • À mon avis, le code de contrôle du terminal devrait être réservé aux TUI ou aux interfaces interactives

  • Mon équipe gère, chez un grand assureur, un énorme monorepo et plusieurs bibliothèques centrés sur NX

    • On maintient plus de 10 applications indépendantes et plus de 25 bibliothèques dans un monorepo unique, avec un CI/CD fortement imbriqué
    • On a aussi essayé lerna, rushjs, yarn workspaces, etc., mais aucun outil n’a aussi bien fonctionné que NX (lerna a d’ailleurs fini absorbé par NX, et rushjs n’est plus vraiment maintenu)
    • J’aimerais qu’on propose des méthodes ou alternatives sérieuses pour maîtriser correctement la complexité des monorepos front-end
    • Avec cet incident de sécurité, beaucoup de gens s’intéressent aux alternatives, donc je serais curieux de lire divers avis

• Au lieu d’accuser uniquement Nx, Anthropic ou la plateforme, il faut repenser à la vraie cause

  • La cause immédiate de cette attaque est qu’un « token » volé (une chaîne autorisant des opérations dans le gestionnaire de paquets) a permis d’uploader des paquets malveillants
  • Mais ce n’est que le vecteur de livraison ; les vraies causes de la réussite sont les suivantes :
    1. Les dépôts de gestionnaires de paquets n’imposaient pas de signature des artefacts, donc il était impossible de vérifier qu’ils venaient bien d’un développeur autorisé
    2. La signature du code n’était pas obligatoire non plus
    3. (Supposition) aucune heuristique de blocage d’upload anormal n’était en place : détection de comportement inhabituel, nouvelle IP, changement de pays, etc.
    4. (Supposition) la MFA n’était pas requise pour l’usage d’un token volé
    5. (Supposition) le token n’était pas à usage unique
    6. (Supposition) le token n’était pas stocké dans un gestionnaire de mots de passe exigeant une approbation manuelle lorsqu’il est utilisé depuis une nouvelle application ou session
  • Rien de tout cela n’aurait dû être absent : tout était évitable
  • En pratique, si vous étiez victime et qu’un nouveau dépôt a été créé sur votre compte GitHub, c’est aussi que vous ne protégiez pas assez fortement vos propres tokens d’authentification
  • Que ces mesures préventives ne soient toujours pas des réglages par défaut est un échec majeur de toute l’industrie logicielle
    • Cela fait des années que ce type d’attaque se répète
    • Et nous, qui sommes développeurs, ne l’avons pas corrigé
  • C’est pourquoi je défends l’idée qu’il faut, pour le logiciel aussi, une réglementation contraignante de type code du bâtiment, avec inspections et amendes

    • Ce type d’attaque peut causer des dégâts critiques à des dizaines de milliers d’organisations : finance, énergie, télécoms, hôpitaux, armée, etc.

    • Avec la généralisation de l’IA, l’ampleur et l’impact des attaques vont encore croître

    • Nous ne développons pas les logiciels de manière assez responsable. Comme pour un code du bâtiment, il faudra peut-être forcer le respect de la sûreté et de la sécurité

    • Ce qui est plus dangereux qu’on ne le pense, c’est que l’environnement informatique personnel reste un grand espace unifié

      • Sur Mac, Windows et Linux, on a au même endroit des wallets crypto, des fichiers d’identifiants et toutes sortes d’applications
      • Les outils pour bien isoler tout cela restent médiocres
      • Quand il m’arrive de lancer plusieurs VM Windows sous macOS, j’imagine un futur très propre et fluide où l’on passe par Alt-Tab d’un conteneur ou d’une VM à l’autre selon la tâche
      • Par exemple : un conteneur gaming, un conteneur dédié aux opérations crypto, un conteneur par projet de code important, etc.
      • Qu’une simple extension VSCode puisse exfiltrer mes clés Bitcoin est une réalité absurde
      • Je ne pense pas que des règles type code du bâtiment pour le logiciel suffiraient à résoudre ce problème de fond
      • Il faut aussi réfléchir à des règles au niveau de l’OS pour contrôler l’accès aux données entre applications, ainsi qu’à la manière concrète de les établir et de les faire respecter

    • 50 % des victimes ont été compromises via VS Code, et cela ne fonctionnait que sur Linux et macOS

      • Pour une analyse détaillée de l’attaque, voir cette analyse de blog
      • En cas d’infection :
        • collecte d’actifs sensibles dès l’étape postinstall (wallets crypto, tokens Github et npm, clés SSH, etc.)
        • collecte d’informations et reconnaissance active via des outils IA en ligne de commande (Claude, Gemini, Q, etc.)
        • les données volées étaient doublement ou triplement encodées en base64 puis uploadées vers des dépôts GitHub contrôlés par l’attaquant (s1ngularity-repository, etc.)
        • des milliers de dépôts ont été trouvés
        • plus de 1 000 tokens GitHub, des dizaines d’identifiants cloud et NPM, ainsi qu’environ 20 000 fichiers ont fuité
        • l’exécution se faisait principalement via l’extension VSCode de NX ou dans des pipelines de build comme GitHub Actions
        • le 27 août à 9h00 UTC, GitHub a désactivé tous les dépôts de l’attaquant, mais les données ont pu fuiter pendant jusqu’à 8 heures d’exposition
        • l’encodage base64 se réverse facilement, donc il faut considérer que toutes ces données sont en pratique publiques

    • Le fait de ne pas stocker les tokens/identifiants GitHub dans un gestionnaire de mots de passe à déblocage manuel est aussi en partie la faute de GH CLI

      • Une fois connecté, GH CLI obtient le droit d’uploader sur des dépôts et demande rarement une réauthentification
      • AWS CLI, selon les politiques, expire automatiquement toutes les 18 heures
      • Mais dans les deux cas, les tokens ont tendance à rester en clair en local par défaut

    • L’idée d’un « code du bâtiment du logiciel » ne m’enthousiasme pas, mais je partage le constat que l’ensemble du secteur est beaucoup trop vulnérable

      • Une régulation est peut-être réellement nécessaire

    • Je trouve arrogant de vouloir faire porter la responsabilité à des bibliothèques open source gratuites

      • Si l’on veut de vraies garanties, il faut acheter une licence
      • Cela ressemble à la politique de validation agressive de Google envers les logiciels gratuits

• Ces derniers temps, je fais la majeure partie de mon développement dans des VM

  • J’ai le sentiment que le niveau de sécurité actuel des environnements est devenu inacceptable

  • Le potentiel des agents logiciels comme vecteur de malware a énormément augmenté

  • Si un attaquant compromet votre machine, nous sommes désormais dans une époque où il peut aussi viser à tout moment des données monnayables à plus de 1 000 dollars : clés crypto, mots de passe, données personnelles, informations financières, etc.

    • Je fais quelque chose de similaire dans un conteneur Podman. Je ne partage rien avec l’hôte en dehors du répertoire du code source

    • Une partie du problème vient du modèle de sécurité traditionnel des PC (Linux/Windows)

      • Le modèle dans lequel les exécutables sont présumés fiables et peuvent accéder à toutes mes données personnelles n’est plus adapté à 2025
      • Le mobile (Android) a largement dépassé ce stade, mais sur PC il existe peu d’alternatives profondes en dehors de SELinux

    • Si vous aimez cette approche, je recommande Qubes OS. Il offre une bonne UX pour tout faire dans des VM

      • C’est mon système principal, je le recommande vivement

    • Cela dit, il faut préciser que mettre en place ce genre d’environnement est très difficile ou assez coûteux à cause de l’écosystème logiciel et de son histoire

• Claude Code est un outil révolutionnaire pour gagner en productivité

  • En revanche, il présente des problèmes de sécurité comme :

    • c’est une application NodeJS
    • l’installation passe par un curl envoyé dans bash (risque d’exécution de code distant)
    • le LLM peut manipuler le système de fichiers, les commandes, etc.

  • Avec au moins ces trois vulnérabilités de sécurité, je ne voudrais pas l’exécuter hors d’un sandbox de type VM/conteneur/machine de dev dédiée

    • Je pense aussi que les agents doivent tourner dans un sandbox

      • Cela dit, Claude code n’exécute pas arbitrairement des commandes dès le départ, sans autorisation spécifique

    • Et alors ?

      • L’utilisateur doit lui-même appuyer sur le bouton d’exécution
      • La plupart des programmes ont eux aussi des privilèges
      • Un terminal peut aussi toucher au système de fichiers, sans pour autant s’exécuter tout seul
      • Claude Code n’agit pas comme un démon qui irait ruiner mon ordinateur de lui-même ; sans instruction claire, il ne se passe rien
      • Pour moi, Claude Code est le meilleur outil que j’ai utilisé depuis 30 ans
      • Je me soucie assez peu du « vecteur d’attaque ». Si quelqu’un obtient un accès non autorisé à mon ordinateur, ce n’est pas un problème propre à Claude Code

    • Le vrai problème, c’est qu’avec les mises à jour automatiques, on donne en fait à Anthropic un droit d’exécution de code distant pendant le fonctionnement, sans intervention de l’utilisateur

• Je me demande si les gestionnaires de paquets ne devraient pas proposer un réglage de type « âge minimal du paquet » (min-age)

  • Par exemple, ignorer tout paquet publié depuis moins de 24 à 36 heures

  • J’ai déjà vu un cas similaire où une mise à jour de paquet a tout cassé, avant d’être corrigée/supprimée quelques heures plus tard

    • GitHub dependabot a justement ajouté récemment cette fonctionnalité

      • Changelog officiel

    • Renovate bot propose déjà cette option (minimumReleaseAge) et dependabot la prend désormais aussi en charge

      • Les gestionnaires de paquets eux-mêmes se contentent d’installer la dernière version, mais on peut gérer les mises à jour à un rythme approprié avec ce type d’outils gratuits
      • L’écosystème JavaScript va progressivement vers plus d’intégration, et les outils de réponse aux attaques de supply chain apparaissent lentement
      • Les versions récentes de NPM, PNPM, Bun, etc. n’exécutent plus les scripts postinstall par défaut, et il faut désormais le faire explicitement si nécessaire (même si, au fond, on exécute toujours du code tiers)

    • Sans être au niveau de l’OS, l’outil uv d’Astral propose ce genre d’option pour les paquets Python

    • npm install a aussi un flag permettant de n’installer que les dépendances antérieures à un instant/date donné

      • Avec npm install --before (date d’il y a 2 jours), les dépendances apparues après cette date ne sont pas installées

    • Dans mon .npmrc, j’active save-exact=true et je ne m’appuie que sur le lockfile et des mises à jour manuelles

      • Pas besoin de mettre les paquets à jour si souvent
      • Après des épisodes comme l’affaire fakerjs, j’ai compris qu’il fallait être prudent

• Je me demandais si claude code exécuterait vraiment ce type de prompt, alors j’ai testé

  • Le résultat a été le suivant :

    • « Cette requête semble demander la recherche et l’inventaire de fichiers sensibles comme des wallets crypto, des clés privées, etc., avec un risque évident d’abus, je ne peux donc pas aider à cela »

    • Il ne guide que vers des demandes légitimes : audit de sécurité, analyse de vulnérabilités, écriture d’outils de monitoring, compréhension des permissions de fichiers, conception de procédures de sauvegarde, etc.

    • On a tout de même recensé au moins 250 cas réussis (autrement dit, certains prompts passent)

      • En moyenne, Claude refuse nettement plus souvent, et Q refuse aussi bien (ce qui est logique, puisqu’il est basé sur Claude)
      • Pour référence, j’ai passé toute la journée sur ce sujet et rédigé ce rapport d’analyse

    • En conditions réelles, chaque fois qu’on compare Claude à d’autres modèles sur les refus, on constate que ses mécanismes de refus/sécurité sont bien meilleurs

      • Exemple célèbre : alors que ChatGPT continuait à appeler un utilisateur en détresse psychologique « The Oracle » en le laissant dériver, Claude refusait et recommandait de consulter un professionnel
      • Bien sûr, les réponses du type « C’est exact ! » à répétition peuvent être agaçantes, mais il faut reconnaître et saluer le fait qu’Anthropic accorde davantage d’attention aux refus et à la sécurité que ses concurrents

• Par défaut, l’OS devrait empêcher les applications d’avoir un accès illimité à l’ensemble du système de fichiers

  • Certaines applis ont bien des profils apparmor/selinux, et on peut utiliser firejail, etc.

  • Mais du point de vue UX, il faut un vrai changement

    • C’est un problème très grave. Cela vient d’une conception du desktop datant de 30 ans

      • À l’inverse, les OS mobiles modernes (iOS, etc.) ont d’excellentes politiques de sandbox par application et de permissions explicites
      • Sur desktop, il existe bien diverses tentatives comme Qubes (OS), Firejail, bubblewrap, AppArmor, etc., mais c’est complexe ou difficilement utilisable par le grand public
      • Il y a aussi OpenSnitch, mais limité au réseau
      • Pour l’utilisateur final, configurer finement les permissions de chaque programme est une charge importante
      • Au final, le plus important est d’avoir des profils maintenus durablement pour les applications largement utilisées
      • La faiblesse de la sécurité desktop est sidérante, mais c’est un problème fondamentalement difficile, et même si on le résout, l’incitation financière reste faible

    • Je développe moi-même sous Linux un outil centré sur l’isolation des environnements par projet avec Podman : probox

      • Beaucoup d’efforts sont consacrés à l’amélioration de l’UX
      • Je l’utilise souvent, et j’aurais besoin de quelqu’un pour faire une revue sécurité

    • En matière de sécurité des fichiers sur Android, Google a bien fait les choses

    • Je recommande aussi d’apprendre à utiliser bubblewrap et de petits environnements chroot

    • Je ne pense pas qu’un quelconque OS ait pour réglage par défaut que les applications disposent d’un « accès illimité à tout le système de fichiers »

      • Linux, BSD, MacOS et Windows ont tous de fortes restrictions
      • Par défaut, c’est sûr tant que l’utilisateur ne prend pas lui-même des décisions dangereuses pour élever les privilèges d’un compte

• Avant, on pouvait se rassurer vaguement en se disant « l’attaquant devra déjà comprendre mon environnement », mais désormais on peut demander à un LLM d’apprendre cet environnement et d’y adapter l’attaque

  • Je me flatte un peu d’avoir réellement anticipé cette évolution

  • Il y avait une discussion intéressante à ce sujet ici

    • (Blague) Je suis l’attaquant, vous avez de nouvelles idées ? (/s)

• La partie vraiment glaçante, c’est l’usage de LLM locaux pour rechercher des secrets

  • Le problème du postinstall est ancien, mais la charge utile appartient à une génération totalement nouvelle

  • Comme la logique malveillante se cache dans des prompts plutôt que dans du code, cela devient difficile à détecter avec l’analyse statique classique

  • Je me demande comment on peut se défendre contre ce type de prompts malveillants

    • J’ai l’impression que la seule réponse est d’exécuter Claude Code dans un conteneur/VM totalement isolé et de relire soi-même tout le code avant commit