La solution aux 99 % des problèmes de sécurité d'OpenClaw a-t-elle été trouvée ?
Des experts d'Echo et NanoCo ont présenté une solution permettant de réduire radicalement le nombre de vulnérabilités dans OpenClaw, assurant une protection transparente sans modifier les habitudes des utilisateurs.
Comment réduire radicalement le nombre de vulnérabilités dans OpenClaw de manière transparente et sans demander à l'utilisateur de changer ses habitudes ?
Par Eilam Milner, CTO chez Echo, et Gabriel Cohen, PDG de NanoCo
La popularité croissante d'OpenClaw a considérablement élargi l'utilisation des agents IA, mais a également soulevé de sérieuses questions de sécurité sur ce qui se passe lorsqu'on leur donne accès à nos outils et systèmes. Les rapports de nombreux utilisateurs ont révélé que les agents n'agissent pas toujours conformément à l'intention de l'utilisateur et ont exposé des problèmes de sécurité critiques. Par exemple, des cas où des agents OpenClaw ont été installés avec des logiciels malveillants, ont supprimé des boîtes mail et ont effectué des opérations financières erronées.
Le projet open-source NanoClaw a été construit pour répondre à ces problèmes et fonctionne selon plusieurs principes de sécurité : les agents s'exécutent de manière isolée de la station de travail (dans ce qu'on appelle le Sandboxing), ils ne sont pas exposés aux clés d'accès, et l'utilisateur a la pleine capacité de définir des politiques — ce que l'agent est autorisé à faire indépendamment et ce qui nécessite une approbation.
Une nouvelle collaboration entre NanoCo et la société Echo pousse le concept de sécurité encore plus loin — et nettoie également les outils et bibliothèques utilisés par l'agent des vulnérabilités de sécurité. Désormais, les agents peuvent fonctionner dans un environnement exempt de vulnérabilités. Comment fonctionne cette solution ?
Réparer la voiture en roulant
Chaque entreprise de logiciels rencontre des vulnérabilités de sécurité (CVE) dans les bibliothèques open-source. La solution à ces vulnérabilités repose sur une communauté mondiale de bénévoles appelés Maintainers. L'ensemble du processus, du moment où le correctif est trouvé par les Maintainers jusqu'à son implémentation dans l'organisation finale, prend en moyenne environ 180 jours. La solution d'Echo raccourcit le processus à 24 heures entre le moment où le correctif est publié et celui où il est utilisé dans les environnements de production.
Cela nous amène à l'environnement d'exécution de NanoClaw, qui comprend une large collection de bibliothèques open-source : Chromium, Node.js, Bun, pnpm, Corepack, Git, curl et unzip. Chacun de ces paquets contient des dizaines de vulnérabilités de sécurité.
La collaboration entre les deux entreprises israéliennes vise à répondre à la question : comment réduire radicalement le nombre de vulnérabilités, de manière transparente et sans demander à l'utilisateur de changer les tâches, les habitudes ou la manière dont l'agent est utilisé ?
Le défi principal : les vulnérabilités marquées comme Won't fix
Dans le cadre de la collaboration, nous avons chez Echo reconstruit l'image de conteneur (Container Image) de NanoClaw de manière durcie — nettoyée de 99 % des vulnérabilités de sécurité existantes.
Le processus commence par l'analyse de l'environnement NanoClaw à l'aide de plusieurs scanners de vulnérabilités indépendants : Trivy, Grype et Wiz. L'utilisation de plusieurs outils donne une image plus complète et fiable, car chaque scanner s'appuie sur des bases de données et des règles d'identification différentes.
Après le mappage, nous avons divisé les résultats en deux groupes : les composants qui peuvent être mis à niveau en toute sécurité et les composants nécessitant un travail individuel. Chromium, par exemple, a pu être mis à jour avec une confiance relative, mais même après avoir supprimé les vulnérabilités qui lui étaient associées, il restait environ 600 vulnérabilités nécessitant un traitement supplémentaire.
Le défi le plus complexe concernait les vulnérabilités marquées comme Won't fix — celles que les gestionnaires de distribution ne corrigent que dans de nouvelles versions qui ne sont pas nécessairement compatibles avec la version utilisée par les utilisateurs finaux. Dans ces cas, nous avons utilisé le Backporting : nous avons pris un correctif officiel d'une version plus récente et l'avons adapté à la version dont dépend NanoClaw. Le processus est effectué à l'aide d'agents IA dédiés, spécialisés dans la recherche de correctifs et leur adaptation. Pour chaque correctif, il est nécessaire de localiser le bon Commit, de s'assurer qu'il est complet et sûr, de l'appliquer sans compromettre la compatibilité et de vérifier que la vulnérabilité a bien été fermée.
Le Dockerfile de NanoClaw est basé sur Debian 12, et le système d'exploitation d'Echo est compatible avec lui, mais avec une différence fondamentale : il est exempt de vulnérabilités et constamment durci par les agents de l'entreprise. Il est compatible avec les distributions Upstream populaires (Ubuntu, Debian, RHEL), dans le but de permettre un processus transparent pour les utilisateurs finaux sans changement de code de leur part.
Une fois que les analyses confirment que tous les correctifs disponibles ont été appliqués, l'image est construite et transférée vers l'Echo Store. De là, elle est synchronisée avec le registre dédié de NanoClaw. Le processus ne s'arrête pas à la première publication : l'image continue d'être surveillée, et lorsque de nouveaux correctifs deviennent disponibles, elle est mise à jour et republiée.
Deux couches de sécurité qui se complètent
À la fin du processus, nous avons réussi à réduire le nombre de CVE d'environ 99 %.
La connexion entre les deux solutions crée une protection en deux couches. La première protège la station de travail en permettant à l'agent de fonctionner dans un environnement de travail séparé (le Sandbox). La deuxième couche durcit les outils utilisés par l'agent, réduisant ainsi la possibilité qu'un attaquant exploite le navigateur ou l'outil système pour pénétrer dans son environnement.
Aucune des couches ne remplace l'autre. Un environnement durci sans isolation donne toujours à l'agent trop de liberté d'action, et l'isolation sans durcissement laisse dans l'environnement de l'agent des composants vulnérables qui pourraient transformer un fichier en point d'entrée vers l'organisation. À mesure que les agents IA reçoivent plus de responsabilités, il ne suffit plus de demander ce qu'ils sont autorisés à faire. Il faut également vérifier sur quoi ils fonctionnent et qui maintient ces outils.
