La cybersécurité fonctionne désormais comme une preuve de travail (Proof of Work)

• Le LLM « Mythos » d’Anthropic exécute des simulations complexes d’attaques réseau plus vite et avec plus de précision que les humains, et son accès est réservé à un nombre limité de développeurs clés
• Lors des tests de l’AI Security Institute, Mythos a réussi entièrement une simulation d’attaque contre un réseau d’entreprise en 32 étapes dans 3 cas sur 10, avec des performances qui s’améliorent à mesure que le budget en tokens augmente
• Ces résultats montrent que la sécurité évolue vers une structure où la défense exige d’engager plus de tokens que l’attaquant, autrement dit une concurrence de type preuve de travail
• Après les attaques de chaîne d’approvisionnement visant LiteLLM et Axios, les tentatives se multiplient pour remplacer les dépendances open source par des LLM ou renforcer la sécurité en injectant des tokens
• La sécurité est de moins en moins déterminée par la créativité technique et de plus en plus par le volume de ressources engagées, ce qui conduit à ajouter une étape de « hardening » au processus de développement

---

Une sécurité qui fonctionne comme une « preuve de travail »

• Le LLM « Mythos » d’Anthropic affiche d’excellentes performances sur des tâches de sécurité informatique, au point que son accès est limité aux principaux créateurs de logiciels au lieu d’être rendu public
  • Mythos exécute des simulations complexes d’attaques réseau bien plus vite que les humains
  • Dans les évaluations de l’AI Security Institute (AISI), il a également démontré une capacité d’exécution de cyberattaques supérieure d’un niveau aux modèles précédents
• Dans « The Last Ones », une simulation d’attaque contre un réseau d’entreprise en 32 étapes, Mythos a totalement réussi 3 fois sur 10
  • L’AISI a utilisé 100 millions de tokens (environ 12 500 dollars) par tentative
  • Parmi les modèles testés, seul Mythos a mené l’attaque jusqu’au bout, et ses performances continuent de progresser à mesure que le budget en tokens augmente
• Ce résultat ramène l’économie de la sécurité à une formule simple : « pour se défendre, il faut dépenser plus de tokens que l’attaquant »
  • Le renforcement de la sécurité dépend davantage du volume de ressources engagées que de la créativité
  • Cela ressemble au mécanisme de preuve de travail (Proof of Work) des cryptomonnaies, où l’emporte celui qui mobilise le plus de ressources de calcul

Ce que révèle cette nouvelle économie de la sécurité

• Renforcement de l’importance des logiciels open source

  • Après les récentes attaques de chaîne d’approvisionnement contre LiteLLM et Axios, certains proposent de réimplémenter le code des dépendances avec des agents IA
  • Andrej Karpathy a déclaré que « les dépendances doivent être réévaluées » et qu’il vaut mieux implémenter directement les fonctions simples avec un LLM
  • Si la sécurité est proportionnelle au nombre de tokens investis, plus les entreprises injectent des tokens pour renforcer la sécurité des bibliothèques open source, plus elles peuvent devenir sûres
  • Mais les OSS largement utilisés ont aussi une forte valeur pour les attaquants, ce qui les incite eux aussi à engager davantage de ressources

• Ajout d’une étape de « hardening » au processus de développement

  • Aujourd’hui, les développeurs suivent un processus en deux étapes : développement → revue de code, avec des modèles différents à chaque étape
  • Anthropic propose un service dédié à la revue de code (Code Review), à un coût d’environ 15 à 20 dollars par revue
  • À l’avenir, un cycle en trois étapes pourrait devenir la norme : développement → revue → hardening
    1. Développement : implémentation des fonctionnalités et itérations fondées sur les retours des utilisateurs
    2. Revue : documentation, refactoring et amélioration de la qualité
    3. Hardening : recherche automatique de vulnérabilités dans les limites du budget disponible
  • La première étape est limitée par le temps humain, la dernière par le coût

Structure des coûts et limites de la sécurité

• L’écriture du code elle-même reste peu coûteuse, mais garantir la sécurité exige d’acheter plus de tokens que l’attaquant
• Même si l’efficacité d’inférence des modèles s’améliore, le coût du renforcement de la sécurité reste déterminé par la valeur de l’attaque, ce qui rend difficile une baisse complète des coûts
• En conséquence, la sécurité se transforme d’un enjeu de créativité technique en une concurrence de ressources fondée sur le marché

[GN⁺]

Commentaires sur Hacker News

• L’accès à la base de code est le point clé. Le scan de sécurité basé sur des LLM actuel revient en pratique à un simple script bash qui parcourt tous les fichiers en lançant un prompt du type « trouve des vulnérabilités »
  Mais si le défenseur contrôle l’ensemble du code source, il peut fonctionner de façon bien plus efficace. Par exemple, il peut ne scanner que les fichiers modifiés dans une PR, ou allouer davantage de tokens au code lié à la sécurité. L’attaquant doit rescanner à chaque fois, alors que le défenseur peut identifier à l’avance toutes les vulnérabilités potentielles en un seul scan
  Au final, il existe une asymétrie des coûts, ce qui donne l’avantage au camp de la défense en matière d’efficacité. L’attaquant doit réussir une chaîne d’exploits à plusieurs étapes, tandis que le défenseur n’a besoin de bloquer que le maillon le plus faible

  • Il y a beaucoup d’attaquants et un seul défenseur, donc l’idée que les économies d’échelle favorisent la défense n’est pas très convaincante. Supposer que l’accès au code est impossible n’est pas une bonne posture de sécurité. Toute revue de sécurité part du principe qu’on a accès au code source
  • Malgré tout, cette approche augmente le coût du développement logiciel. Une attitude désinvolte du genre « qui s’intéresserait spécifiquement à nous ? » ne tient plus
  • Comme cela a été mentionné récemment dans le podcast Security Cryptography Whatever, il était intéressant de voir qu’en ce moment, « attendre le prochain modèle » est plus efficace que d’améliorer le harness
  • Le problème, c’est que cette approche peut faire passer un incident du niveau « un PC de développeur compromis dans une attaque de supply chain » au niveau « fuite complète du code source et audit automatisé ». Un tel monde ressemble à une forêt sombre pour les startups
  • Le défenseur doit tout renforcer, mais l’attaquant n’a besoin de trouver qu’une seule faille

• Le AI Security Institute (AISI) mentionné dans l’article m’a intrigué, donc je suis allé regarder : c’est surtout une organisation à laquelle participent des personnes venant de DeepMind ou OpenAI. On y trouve très peu de professionnels du secteur de la sécurité. Du coup, la conclusion selon laquelle « pour durcir les systèmes, il faut utiliser plus de tokens » sonne un peu comme un raisonnement centré sur l’industrie de l’IA. Je me demande aussi pourquoi des alternatives comme la vérification formelle (formal verification) ne sont pas mentionnées. On peut imaginer NVIDIA utiliser ce type d’argumentaire pour vendre des GPU

  • Je me demande quel chercheur en sécurité connu défendrait la position opposée. En pratique, beaucoup semblent être d’accord avec cette thèse. Le débat actuel porte surtout sur le fait de savoir si les LLM représentent une innovation du niveau du fuzzing, ou davantage
  • Pour référence, l’AISI est une agence du gouvernement britannique, rattachée au Department for Science, Innovation and Technology (DSTI). En revanche, leur manière de faire l’analyse, par exemple en traçant des graphes simplement linéaires, est un peu décevante

• Comme le disait Tony Hoare : « il existe deux façons de concevoir un logiciel : soit il est si simple qu’il n’a manifestement pas de défauts, soit il est si complexe qu’il n’a pas de défauts apparents » — une citation marquante

  • Rendre quelque chose complètement simple ne bloque pas toutes les attaques, mais réduire la surface d’attaque a un effet important. Par exemple, si l’on conçoit un système de sorte qu’une vérification de signature soit obligatoire avant tout traitement de message réseau, il devient difficile d’accepter des messages non signés. Beaucoup de systèmes actuels ont un modèle de menace plus large que nécessaire
  • Mais le critère de « complexité » n’est pas le même pour les humains et pour les LLM. Ce qui paraît complexe à un humain peut être simple pour un LLM. Donc on peut douter de l’efficacité réelle de cette approche

• La sécurité a toujours été un jeu où tout dépend de l’argent que l’adversaire est prêt à dépenser. L’arrivée des LLM ne change pas le principe. La philosophie de Karpathy, « copier plutôt que dépendre », existait déjà sous forme d’adage dans le langage Go. Le principe selon lequel « on n’obtient pas la sécurité par l’obscurité » est lui aussi ancien

  • Cela dit, l’obscurité (obscurity) n’est pas totalement inutile. Elle peut aider comme l’une des couches de défense. L’idéal est de renforcer un système en supposant une transparence totale, puis d’y ajouter un peu d’opacité par-dessus
  • L’idée qu’« il faut dépenser plus de tokens que l’attaquant pour pouvoir se défendre » n’a rien de nouveau. C’était déjà vrai pour la sécurité physique. Au final, à l’ère de l’IA, il faudra aussi défendre l’IA avec de l’IA. Il faudrait commencer par examiner les prompts des modèles de génération de code utilisés par les développeurs

• Je suis globalement d’accord avec l’article. La formule « on ne marque pas des points avec l’intelligence » est un peu dangereuse. Au fond, l’essence de la cybersécurité reste un système humain. Utiliser beaucoup de temps GPU est nécessaire, mais au bout du compte, c’est la culture et la discipline de sécurité d’une organisation qui déterminent l’issue. Il faut un niveau de discipline comparable à celui qui n’apparaît souvent qu’après des accidents dans le nucléaire ou l’aéronautique.
  Dans ce contexte, ce texte publié il y a un an décrivait presque prophétiquement la situation actuelle

• À propos de l’affirmation selon laquelle « pour durcir un système, il faut utiliser plus de tokens que l’attaquant », j’ai déjà écrit moi-même des scripts pour automatiser l’API de Ticketmaster par le passé. Ils avaient renforcé leur défense avec PerimeterX, mais je l’ai contournée en trois jours. Plus récemment, j’ai implémenté quelque chose de similaire pour contourner le Cloudflare Turnstile de ChatGPT.
  C’était un bon exemple montrant que des produits de sécurité développés pour des dizaines de millions de dollars peuvent en pratique être complètement inutiles
  Discussion HN liée

• Je me demande si les incidents de sécurité trouvés par les LLM sont réellement de nouvelles vulnérabilités, ou simplement le prolongement de connaissances de sécurité déjà existantes. Si c’est la deuxième hypothèse, pourquoi sommes-nous incapables de les trouver nous-mêmes de façon systématique ?

• Si cette recherche ressemble à du Proof of Work, c’est parce que l’AISI indique que « les performances continuent d’augmenter à mesure qu’on utilise davantage de tokens ». Autrement dit, l’hypothèse est que le taux de réussite de l’attaque est proportionnel à la consommation de tokens. Mais l’expérience portait sur un scénario d’intrusion réseau en 32 étapes, et le seul modèle à l’avoir mené à bien était Mythos. Sur une simple bibliothèque de code, le point de rendement décroissant pourrait arriver bien plus tôt
  Les projets open source pourraient atteindre cette limite plus rapidement, puisque défenseurs et attaquants y consomment tous deux beaucoup de tokens

  • Mythos n’a pas réussi toutes les tentatives, et le réseau expérimental ne disposait pas non plus de véritables défenses. Malgré cela, il n’y a aucune raison de sous-estimer l’IA. Dans trois mois, les modèles seront encore à un autre niveau
  • Je ne connais pas très bien la cybersécurité, mais le point clé me semble être le taux d’augmentation du coût en tokens pour passer de 32 à 33 étapes. Si la défense est indépendante à chaque étape, alors la probabilité de succès de l’attaque chute rapidement en p^N

• Au final, la vraie question est la suivante : qu’est-ce qui coûte le moins cher à protéger, une base de code écrite par des humains, ou du code généré par une armée d’agents ?

• Continuer à jeter les modèles sur une base de code entière, comme on le fait aujourd’hui, est inefficace. D’après mes expériences, quand on ajuste le modèle pour explorer de manière structurée une trace source-to-sink dans le code, le coût baisse fortement.
  Nous sommes désormais entrés dans une époque où les systèmes peuvent visualiser le contexte de l’ensemble du code et repérer précisément les points de rupture. Cela pourrait marquer un tournant majeur pour l’amélioration de la qualité logicielle