L’IA cybersécurité peut-elle trouver des failles oubliées ?

L’IA cybersécurité peut analyser du code à une échelle que les humains ne peuvent pas tenir seuls. L’exemple Claude Mythos montre comment un modèle peut repérer des zero-days, dont une faille restée cachée environ 27 ans dans OpenBSD.

Que montre l’affaire Claude Mythos ?

Claude Mythos montre qu’un modèle d’IA peut aider à découvrir des vulnérabilités anciennes, complexes et passées sous les radars des audits humains.

Claude Mythos est un projet de recherche en sécurité d’Anthropic qui utilise le modèle Claude pour analyser massivement du code source réel. Il ne s’agit pas d’un simple scanner de signatures, c’est-à-dire d’un outil qui cherche des motifs déjà connus dans du code ou des fichiers. Le système tente plutôt de raisonner sur ce que fait le code, sur l’intention probable du développeur et sur les enchaînements logiques qui peuvent produire un comportement dangereux.

L’exemple le plus frappant concerne une vulnérabilité présente dans OpenBSD depuis environ 1997, soit près de 27 ans, découverte lors de cette analyse. OpenBSD n’est pas un projet quelconque. C’est un système d’exploitation connu pour sa culture de l’audit de sécurité, avec une attention historique portée à la relecture du code, à la réduction de la surface d’attaque et à la correction préventive des bugs. Quand une faille aussi ancienne ressort dans une base de code aussi surveillée, le signal devient difficile à ignorer.

Deux termes méritent d’être posés clairement.

• Une vulnérabilité zero-day est une faille inconnue publiquement et sans correctif disponible au moment de sa découverte.
• Une base de code est l’ensemble des fichiers sources qui composent un logiciel, avec ses bibliothèques, ses modules, ses tests et parfois des décennies d’historique technique.

Ce cas ne prouve pas que l’IA remplace les chercheurs en cybersécurité. Il montre plutôt qu’elle peut explorer autrement des volumes de code trop vastes, trop anciens ou trop imbriqués pour être relus efficacement à la main. La vraie question devient donc plus précise : qu’est-ce que l’IA détecte mieux que les humains, et comment éviter que cette même capacité serve aussi à automatiser la recherche de failles pour attaquer ?

Pourquoi les humains ratent-ils ces failles ?

Les humains ratent certaines failles parce que les bases de code modernes sont trop vastes, trop anciennes et trop contextuelles pour être auditées intégralement à la main.

Le premier problème est l’échelle. Une équipe sécurité doit choisir où passer son temps. Elle va naturellement regarder les composants récents, exposés sur Internet, liés à l’authentification, au paiement, aux droits d’accès ou au traitement de données sensibles. Le code jugé stable, lui, peut rester peu relu pendant des années.

Ce n’est pas un problème d’incompétence. C’est un problème de coût, de temps et de charge cognitive. Relire proprement du code demande de comprendre l’intention métier, les dépendances, les anciennes décisions techniques, les cas limites et les effets de bord. Même un bon auditeur finit par prioriser, parce que tout vérifier au même niveau de détail n’est pas réaliste.

Le deuxième problème est le contexte. Certaines vulnérabilités ne sont pas visibles dans une fonction isolée. Elles apparaissent seulement quand plusieurs appels se combinent, quand une donnée change de type, quand une entrée utilisateur contourne une hypothèse ou quand un état inattendu survient à l’exécution.

Un exemple simple suffit. Une donnée utilisateur peut être validée trop tôt, puis transformée trois fonctions plus loin, avant d’être copiée dans une zone mémoire trop petite. Chaque fonction, lue séparément, peut sembler correcte. La validation existe. La transformation paraît normale. La copie semble banale. Le risque apparaît seulement en suivant le chemin complet de la donnée, du point d’entrée jusqu’à l’opération dangereuse.

C’est précisément là qu’une IA peut aider, sans remplacer l’expertise humaine. Elle peut parcourir beaucoup de code, repérer des motifs suspects, relier des appels éloignés et signaler des chemins à vérifier. Le gain n’est pas magique. Il vient surtout de la capacité à explorer plus large et à attirer l’attention sur des zones que personne n’aurait eu le temps de relire.

Problème d’échelle	Un humain doit prioriser, car auditer tout le code ligne par ligne coûte trop cher et prend trop de temps.	Une IA peut analyser de grands volumes de code et proposer une liste de zones suspectes à examiner en priorité.
Problème de contexte	Un humain peut manquer une faille qui n’apparaît qu’après plusieurs appels, transformations ou changements d’état.	Une IA peut suivre des flux de données et repérer des combinaisons risquées entre fonctions éloignées.
Dette historique du code	Un humain relit rarement du code ancien considéré comme stable, surtout si la connaissance métier a disparu.	Une IA peut revisiter du code oublié avec des règles récentes et faire remonter des hypothèses de vulnérabilité.

Que fait l’IA différemment ?

L’IA fait différemment parce qu’elle peut relier des morceaux de code éloignés et raisonner sur leur sens, pas seulement chercher des motifs connus.

Un scanner traditionnel fonctionne surtout par correspondance. Il compare le code à une base de signatures : fonctions dangereuses, versions de bibliothèques vulnérables, patterns déjà observés dans des failles connues. C’est utile, rapide, industrialisable. Mais ce mécanisme voit mal les bugs qui naissent d’un enchaînement subtil, surtout quand chaque ligne prise séparément semble correcte.

Scanner basé sur signatures	Approche sémantique avec IA
Cherche des formes déjà connues dans le code.	Analyse ce que le code essaie de faire.
Repère une fonction risquée, une version vulnérable ou un pattern précis.	Suit les données, les conversions, les conditions et les effets indirects.
Produit souvent des alertes locales.	Peut relier plusieurs fichiers, appels et étapes d’exécution.

Le raisonnement sémantique consiste à comprendre ce que le code fait réellement, au-delà de sa syntaxe. Par exemple, une valeur peut être reçue comme entier 64 bits, convertie plus loin en entier 32 bits, puis utilisée plusieurs appels après pour définir la taille d’une copie mémoire. Chaque opération peut paraître normale. Mais l’enchaînement peut créer une troncature, donc une taille incorrecte, puis un dépassement de tampon. Un modèle comme Claude Mythos peut signaler ce scénario parce qu’il relie la conversion, la propagation de la donnée et la conséquence possible.

La mémoire de contexte est donc centrale. Garder en tête une chaîne d’exécution complète permet de détecter des bugs logiques que les outils classiques ratent parfois, et que les revues humaines fragmentées peuvent aussi laisser passer. Une équipe relit souvent un module, une fonction, un correctif. La faille, elle, traverse parfois tout le chemin.

Reste un point non négociable : l’IA ne remplace pas la validation humaine. Elle produit des pistes. Certaines seront fausses, théoriques, non exploitables ou déjà couvertes par une autre protection. Les chercheurs doivent vérifier le comportement, reproduire le bug, mesurer l’impact réel, puis coordonner la correction avec les mainteneurs. L’intérêt n’est pas de croire l’IA sur parole, mais d’obtenir de meilleurs indices plus tôt.

Quel risque pour la cybersécurité ?

Le risque est double, car la même capacité peut accélérer la défense logicielle ou automatiser la recherche offensive de failles. Une IA capable d’analyser du code, de repérer des chemins d’exécution suspects et de suggérer des scénarios de test peut aider une équipe sécurité. Elle peut aussi donner plus de vitesse à quelqu’un qui cherche une faille exploitable.

Côté positif, le gain est concret. Les équipes peuvent auditer plus de code, revenir sur des composants anciens rarement relus, prioriser les zones risquées et réduire le stock de vulnérabilités cachées. C’est particulièrement utile pour les logiciels critiques, les bibliothèques open source et les infrastructures utilisées à grande échelle, car une seule faille dans un composant partagé peut toucher des milliers d’applications.

Le point clé reste la priorisation. Une analyse assistée par IA peut aider à repérer les fichiers qui manipulent des données sensibles, les fonctions exposées sur Internet, les dépendances non maintenues ou les zones où beaucoup de corrections ont déjà eu lieu. Ce ne remplace pas un audit humain, mais cela permet de mieux orienter l’effort.

Côté inquiétant, le même mécanisme peut servir à chercher plus vite des zero-days. Un zero-day est une vulnérabilité inconnue de l’éditeur ou non corrigée au moment où elle est découverte. Si des modèles puissants permettent d’industrialiser cette recherche, des acteurs malveillants peuvent tester davantage de logiciels, générer plus d’hypothèses d’attaque et accélérer leurs cycles d’exploitation.

L’enjeu n’est donc pas seulement technique. Il faut contrôler l’accès aux outils, journaliser les usages, imposer une validation humaine, encadrer la divulgation responsable et corriger vite. La divulgation responsable consiste à prévenir les mainteneurs, laisser un délai raisonnable de correction, puis éviter de publier des détails exploitables avant qu’un correctif soit disponible.

Quelques actions simples réduisent déjà le risque :

• Inventorier les dépôts de code, y compris les anciens projets encore en production.
• Identifier les composants vieillissants, non maintenus ou très exposés.
• Intégrer l’analyse assistée par IA dans le cycle de développement, avant la mise en production.
• Garder une revue humaine sur les résultats, surtout pour les alertes critiques.
• Documenter les décisions, les faux positifs et les arbitrages de correction.
• Suivre les correctifs jusqu’au déploiement réel, pas seulement jusqu’au ticket fermé.

Opportunités défensives	Risques offensifs
Auditer plus de code et revisiter des composants oubliés.	Accélérer la recherche automatisée de failles exploitables.
Prioriser les zones critiques et les dépendances sensibles.	Multiplier les tests contre des logiciels largement déployés.
Réduire le stock de vulnérabilités cachées avant exploitation.	Faciliter la découverte de zero-days par des acteurs malveillants.

Alors, faut-il intégrer l’IA à vos audits sécurité ?

L’IA ne rend pas la cybersécurité magique, mais elle change l’échelle du problème. Claude Mythos illustre un point simple : des failles peuvent rester invisibles pendant des décennies, même dans des projets réputés sérieux, parce que le code est immense, ancien et dépendant du contexte. L’intérêt n’est pas de remplacer les experts, mais de leur donner un moyen de repérer plus vite les zones à risque. La bonne approche consiste à combiner analyse assistée par IA, validation humaine et processus de correction rigoureux. Le bénéfice pour vous : réduire les angles morts avant qu’ils ne deviennent exploitables.

FAQ

• Qu’est-ce qu’une vulnérabilité zero-day ?
  Une vulnérabilité zero-day est une faille inconnue publiquement ou non corrigée au moment où elle est découverte. Elle est particulièrement sensible, car aucun correctif n’est encore disponible pour protéger les systèmes concernés.
• Pourquoi une faille peut-elle rester cachée pendant 27 ans ?
  Une faille peut rester cachée si elle se trouve dans une partie ancienne du code, rarement modifiée, ou si elle dépend d’un enchaînement précis d’appels, d’entrées et d’états d’exécution. Les audits humains doivent prioriser, et certains chemins complexes passent inaperçus.
• Claude Mythos est-il un scanner de sécurité classique ?
  Non. Un scanner classique recherche surtout des signatures, des versions vulnérables ou des motifs connus. Claude Mythos utilise le raisonnement d’un modèle de langage pour analyser le sens du code, le contexte et les scénarios d’exploitation possibles.
• L’IA peut-elle remplacer les chercheurs en cybersécurité ?
  Non. L’IA peut accélérer l’analyse et signaler des pistes, mais les humains restent indispensables pour confirmer la vulnérabilité, mesurer son impact, éviter les faux positifs, coordonner la correction et gérer la divulgation responsable.
• Quel est le principal danger de l’IA en cybersécurité ?
  Le principal danger est l’automatisation de la découverte de failles par des acteurs malveillants. La même technologie peut aider les défenseurs à auditer plus de code, mais elle peut aussi réduire le coût de recherche de vulnérabilités exploitables.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les processus business et les sujets SEO/GEO. J’ai travaillé pour des organisations comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez intégrer l’IA, la data ou l’automatisation de façon fiable et utile dans votre entreprise, contactez-moi.