🔬 Contexte et source

Article académique publié sur arXiv (soumis le 23 mai 2026) par des chercheurs de Bynario, Vanta et University College London. Il s’appuie sur les données publiques des campagnes Anthropic Mythos Preview et Mozilla Firefox pour analyser les implications économiques des LLM dans la découverte de vulnérabilités.

📐 Concept central : le « bugonomics »

Les auteurs introduisent le terme bugonomics comme cadre d’analyse des coûts et incitations liés à la production d’artefacts de sécurité. Ils distinguent explicitement plusieurs catégories économiquement distinctes :

  • Rapport candidat : suspicion générée par un modèle
  • Vulnérabilité acceptée : confirmée par le mainteneur
  • Vulnérabilité exploitable : avec chemin d’attaque crédible
  • Chaîne d’exploit : composition opérationnelle sous contraintes réelles

💰 Données publiques analysées

Campagne Mythos Preview (Anthropic) :

  • Coût total < 20 000 $ pour ~1 000 runs
  • « Plusieurs dizaines » de findings (24–48 estimés)
  • Coût par finding estimé : 417–833 $ en génération seule
  • ~4 000 $ pour plusieurs centaines de tentatives d’exploitation → 2 exploits rudimentaires en environnement de test sans défenses

Collaboration Firefox (Anthropic/Mozilla) :

  • 112 rapports soumis, 22 vulnérabilités acceptées (19,6%), 14 haute sévérité (12,5%)
  • Ratio : ~5,1 rapports par vulnérabilité acceptée, ~8 par vulnérabilité haute sévérité
  • Firefox 150 : 271 bugs identifiés par Mythos, dont 180 sec-high, 80 sec-moderate, 11 sec-low
  • 423 corrections de sécurité au total en avril 2026

Ancres marché offensif (2024) :

  • Zero-days iPhone : 5–7 M$, Android : jusqu’à 5 M$, Chrome/Safari : jusqu’à 3 M$

📊 Modèle de coût proposé

Les auteurs formalisent le coût total d’une campagne : C_total = C_G + C_V + C_I + C_R + C_T (génération + validation + impact + remédiation + triage mainteneur)

Ils montrent que la réduction de C_G par les LLM déplace le goulot d’étranglement vers C_V, C_I, C_R et C_T, notamment dans l’open source où la capacité des mainteneurs ne s’adapte pas automatiquement.

🔓 Open source et dette technique

Les auteurs identifient une asymétrie structurelle : les LLM peuvent générer des rapports à vitesse machine, mais les mainteneurs open source absorbent ce volume en heures non rémunérées. La métrique recommandée est corrections acceptées par heure-mainteneur, non le volume de candidats générés.

🧩 Recommandations de reporting

Les auteurs proposent des champs minimaux pour les rapports de campagnes LLM (Table II) : volume brut, déduplication, précision, distribution de sévérité, statut d’exploitabilité, heures de validation, heures de triage mainteneur, coût API/compute.

📌 Type d’article

Publication de recherche académique à visée analytique, dont l’objectif principal est de fournir un cadre économique rigoureux pour évaluer l’impact réel des LLM sur la découverte de vulnérabilités, en s’opposant aux narratifs simplistes d’« apocalypse » ou d’obsolescence défensive.

🔴 Indice de vérification factuelle : 25/100 (basse)

  • ⬜ arxiv.org — source non référencée (0pts)
  • ✅ 65276 chars — texte complet (fulltext extrait) (15pts)
  • ⬜ aucun IOC extrait (0pts)
  • ⬜ pas d’IOC à vérifier (0pts)
  • ⬜ aucune TTP identifiée (0pts)
  • ✅ date extraite du HTML source (10pts)
  • ⬜ aucun acteur de menace nommé (0pts)
  • ⬜ pas de CVE à vérifier (0pts)

🔗 Source originale : https://arxiv.org/abs/2605.24632