IA cybersécurité peut-elle trouver des zero-day ?

L’IA cybersécurité peut repérer des failles zero-day en analysant le sens du code, pas seulement des motifs connus. L’exemple de Claude Mythos montre un vrai changement : plus d’échelle, plus de contexte, mais aussi plus de risques offensifs.

Que change l’IA pour détecter des failles ?

L’IA change la détection de failles parce qu’elle ne se contente plus de chercher une signature déjà connue. Elle peut parcourir de grands volumes de code, relier des fichiers entre eux, suivre des dépendances et raisonner sur les flux d’exécution, c’est-à-dire le chemin réellement pris par les données et les instructions dans un programme.

Une vulnérabilité zero-day est une faille inconnue de l’éditeur, ou connue mais sans correctif public disponible. Elle peut donc être exploitée avant que les défenseurs aient eu le temps de publier un patch, de mettre à jour leurs outils ou de documenter le risque. Le point important : une faille zero-day n’est pas forcément récente. Une erreur peut rester invisible pendant des années si elle se trouve dans une partie du code stable, rarement modifiée ou jugée peu risquée.

C’est là que l’IA apporte quelque chose d’utile. Un analyseur classique repère très bien certains motifs : une fonction dangereuse, une mauvaise validation d’entrée, une configuration faible. Mais il rate plus facilement les défauts qui dépendent du contexte. Par exemple : une donnée semble validée dans un fichier, mais elle est transformée plus loin, puis utilisée dans une fonction sensible avec une hypothèse fausse.

Approche classique	Recherche de règles, signatures et patterns connus.
Approche avec IA	Analyse du contexte, de l’intention du code et des chemins d’exécution possibles.

Claude Mythos s’inscrit dans cette logique : une initiative de recherche en sécurité utilisant Claude pour analyser du code source à grande échelle. Claude est un modèle de langage, donc un système entraîné à comprendre et générer du texte, y compris du code. L’idée centrale n’est pas de remplacer les outils d’analyse statique, mais d’ajouter une couche de raisonnement : pourquoi ce code existe, quelles hypothèses il fait, et dans quelles conditions il peut se comporter dangereusement.

Pour rester sérieux, une alerte doit ensuite être qualifiée. Les vulnérabilités réelles sont généralement référencées dans CVE, pour Common Vulnerabilities and Exposures, une base publique d’identifiants de failles. Les familles d’erreurs sont souvent décrites avec MITRE CWE, pour Common Weakness Enumeration, qui classe les types de défauts comme les injections, dépassements de mémoire ou contrôles d’accès incorrects.

La valeur devient surtout visible quand l’IA retrouve des failles réelles, parfois très anciennes, dans des bases de code réputées solides.

Pourquoi des humains ratent-ils ces bugs ?

Les humains ratent ces bugs parce que le volume de code, l’ancienneté des composants et la complexité des contextes d’exécution dépassent ce qu’une revue manuelle peut couvrir durablement.

Un logiciel moderne n’est pas un fichier propre relu de haut en bas. C’est souvent un empilement de milliers, parfois de millions de lignes de code, avec des bibliothèques externes, des morceaux historiques, des correctifs successifs et des chemins d’exécution rarement empruntés. Le noyau Linux, par exemple, dépasse les 30 millions de lignes de code selon les mesures publiques régulièrement suivies par OpenHub. À cette échelle, même une bonne équipe doit choisir où regarder.

Ces choix sont rationnels. Les équipes sécurité priorisent le code récent, exposé sur Internet, lié à l’authentification, au paiement, aux données personnelles ou aux droits d’administration. Le reste passe après. Résultat : du vieux code “stable” peut rester peu revisité pendant des années, alors qu’il continue de traiter des entrées réelles.

Le deuxième problème est le contexte. Une fonction peut sembler correcte isolément, mais devenir vulnérable quand elle reçoit une valeur particulière, traverse cinq appels, dépend d’un état système précis ou interagit avec une autre fonction. C’est là qu’intervient le flux de données : suivre comment une donnée entre dans le programme, comment elle est transformée, puis comment elle influence une opération sensible, comme une requête SQL, une allocation mémoire, une commande système ou une décision d’autorisation.

Les scanners traditionnels restent utiles. Ils repèrent des motifs connus, des erreurs fréquentes et des règles codifiées, par exemple une fonction dangereuse, une dépendance vulnérable ou une mauvaise configuration. Mais ils sont moins à l’aise avec les vulnérabilités logiques, où le danger ne vient pas d’une ligne suspecte, mais de l’enchaînement complet des opérations.

Revue humaine	Scanner classique	Modèle IA
Échelle : Excellente sur une zone limitée, difficile sur des millions de lignes.	Échelle : Très bon pour parcourir beaucoup de fichiers rapidement.	Échelle : Bon pour explorer de grands volumes, avec une qualité variable selon le modèle et le contexte fourni.
Contexte : Forte compréhension métier, mais mémoire et temps limités.	Contexte : Souvent limité à des règles locales ou prédéfinies.	Contexte : Peut relier plusieurs indices, mais peut aussi surinterpréter.
Faux positifs : Moins nombreux quand l’expert connaît bien le système.	Faux positifs : Fréquents si les règles sont trop larges.	Faux positifs : Possibles, surtout sans exécution ni preuve exploitable.
Failles logiques : Bonne capacité, mais coûteuse en temps.	Failles logiques : Faible si le scénario n’est pas codifié.	Failles logiques : Prometteur pour formuler des hypothèses et suivre des chaînes d’appels.
Priorisation : Très bonne avec connaissance produit.	Priorisation : Basée sur sévérité connue et règles fixes.	Priorisation : Utile pour classer des pistes, mais doit rester validée par un humain.

Comment Claude raisonne-t-il sur le code ?

Claude raisonne sur le code en reliant plusieurs indices : l’intention probable du développeur, le flux de données, les appels de fonctions, les conditions d’exécution et les conséquences possibles d’une entrée malveillante. Il ne se contente pas de chercher un mot comme “admin”, “token” ou “validate”. Il essaie d’estimer ce que le programme autorise réellement.

Le raisonnement sémantique, c’est cette capacité à comprendre le comportement du code, pas seulement sa forme. Deux morceaux de code peuvent contenir la même vérification, mais ne pas offrir la même protection. Une validation peut exister, sembler correcte, et pourtant être placée trop tôt, trop tard, ou sur la mauvaise version de la donnée.

Exemple simple : une donnée utilisateur est vérifiée, puis transformée. Si la transformation réintroduit une valeur dangereuse, la validation initiale ne protège plus vraiment le chemin exécuté.

Fonction traiterMessage(entreeUtilisateur):
    Si contientValeurInterdite(entreeUtilisateur):
        Refuser la requete

    messageNormalise = decoder(entreeUtilisateur)

    Enregistrer(messageNormalise)

Dans ce pseudo-code, la vérification porte sur l’entrée brute. Mais la fonction “decoder” peut modifier son contenu. Une valeur inoffensive en apparence peut devenir problématique après transformation. Le point important n’est pas d’exploiter ce cas, mais de comprendre que la sécurité dépend du chemin complet : entrée, validation, transformation, puis action sensible.

Ce type de raisonnement peut aider à repérer plusieurs familles de failles difficiles à voir avec une simple recherche syntaxique :

• Les erreurs de logique, quand le programme autorise une action dans un ordre imprévu.
• Les validations incomplètes, appliquées à une donnée mais pas à sa version transformée.
• La mauvaise gestion d’état, par exemple un utilisateur considéré comme vérifié trop tôt.
• La confusion entre données fiables et non fiables, notamment entre données internes et entrées externes.
• Les chemins d’exécution rares, déclenchés seulement avec certaines conditions.
• Les interactions entre fonctions éloignées, où le risque apparaît seulement en suivant plusieurs appels.

Mais Claude ne remplace pas une validation sécurité. Une alerte doit être reproduite, testée, triée et confirmée par des experts. Le modèle peut produire des faux positifs, mal interpréter une intention métier, ou halluciner une faille sans preuve exploitable. En cybersécurité, une hypothèse utile reste une hypothèse tant qu’elle n’a pas été confirmée par des tests contrôlés.

Pourquoi l’exemple OpenBSD compte-t-il ?

L’exemple OpenBSD compte parce qu’il rappelle une réalité inconfortable : une faille peut survivre environ 27 ans, même dans un projet reconnu pour sa rigueur de sécurité.

OpenBSD n’est pas un système quelconque. C’est un système d’exploitation libre, issu de la famille BSD, réputé pour son attention portée à l’audit de code, à la simplicité et aux mécanismes de défense intégrés. Le projet met en avant depuis longtemps des pratiques comme la revue manuelle du code, la réduction de la surface d’attaque et des protections mémoire. Cela ne le rend pas invulnérable. Cela montre plutôt que même les équipes sérieuses travaillent sur du code complexe, écrit sur plusieurs décennies, modifié par couches successives et parfois difficile à relire avec un regard neuf.

La portée symbolique est forte. Si une IA peut repérer une vulnérabilité passée sous les radars dans un environnement aussi audité, alors des bases de code moins surveillées peuvent contenir un stock bien plus important de failles dormantes. Beaucoup d’entreprises ont du code ancien, des bibliothèques internes peu documentées, des scripts critiques jamais réaudités et des dépendances open source intégrées depuis des années.

La conséquence pratique est assez directe pour les équipes sécurité :

• Revoir les priorités d’audit : Le code ancien mérite autant d’attention que les nouvelles fonctionnalités.
• Intégrer l’IA dans le cycle de développement sécurisé : L’analyse assistée par IA peut compléter les revues humaines, les tests statiques et les fuzzers, c’est-à-dire les outils qui bombardent un programme avec des entrées imprévues pour provoquer des erreurs.
• Documenter les résultats : Une alerte IA sans preuve, sans reproduction et sans contexte reste insuffisante pour corriger proprement.

Il faut aussi garder la tête froide. Une découverte par IA n’a de valeur que si elle est communiquée de manière responsable, corrigée, documentée et intégrée dans un processus de gestion des vulnérabilités. En cybersécurité, on parle de divulgation coordonnée : le chercheur prévient d’abord l’éditeur ou le mainteneur, laisse un délai raisonnable pour corriger, puis publie les détails une fois le correctif disponible. L’objectif est simple : éviter de donner une recette d’exploitation avant que les utilisateurs puissent se protéger.

Quels risques pour les entreprises ?

Le principal risque pour les entreprises est double : les défenseurs gagnent un outil puissant, mais les attaquants peuvent aussi accélérer la recherche de failles. Une IA capable d’analyser du code à grande échelle peut réduire le bruit côté sécurité, mais aussi réduire le coût d’une attaque côté offensif.

Côté défense, l’IA peut aider les équipes AppSec à mieux cibler leurs efforts. AppSec signifie sécurité applicative : c’est l’ensemble des méthodes utilisées pour concevoir, tester et maintenir des logiciels plus sûrs. Dans une entreprise avec des centaines de dépôts Git, le sujet n’est pas seulement de “trouver une faille”, mais de savoir où regarder en premier.

Les usages défensifs les plus utiles sont assez concrets :

• Analyser des dépôts volumineux pour repérer des zones sensibles : authentification, paiement, gestion des droits, chiffrement.
• Prioriser les revues de code selon le risque métier et l’exposition Internet.
• Détecter des erreurs logiques que les scanners classiques voient mal, par exemple un contrôle d’autorisation oublié.
• Aider les développeurs à appliquer des pratiques de secure coding, c’est-à-dire écrire du code qui évite les failles connues dès la conception.

Côté offensif, le risque vient de l’industrialisation. Si des modèles performants sont utilisés sans garde-fous, ils peuvent accélérer l’analyse de code, générer des hypothèses d’exploitation et réduire le niveau d’expertise nécessaire pour trouver certaines vulnérabilités. Cela ne transforme pas automatiquement chaque attaquant en chercheur zero-day, mais cela augmente la vitesse d’essai, de tri et de validation.

La bonne approche n’est donc pas d’interdire l’IA, mais de l’encadrer. Je recommande une méthode prudente : cartographier les dépôts critiques, lancer des audits IA sur un périmètre limité, exiger une validation humaine, documenter les preuves techniques, intégrer les résultats dans le backlog sécurité, suivre les correctifs et former les développeurs aux familles de vulnérabilités récurrentes décrites par MITRE CWE, la base de référence publique des faiblesses logicielles connues.

Périmètre	Objectif	Risque réduit	Première action à lancer
Code critique	Identifier les zones à fort impact métier.	Faille exploitable sur un service sensible.	Cartographier les dépôts liés à l’authentification, aux paiements et aux données clients.
Dépendances	Repérer les bibliothèques vulnérables ou abandonnées.	Compromission via un composant tiers.	Activer un inventaire logiciel, aussi appelé SBOM, pour lister les composants utilisés.
Validation humaine	Éviter les faux positifs et les conclusions non vérifiées.	Correction inutile ou faille mal comprise.	Imposer une revue AppSec avant toute création de ticket critique.
Gouvernance	Encadrer l’usage des outils IA dans les audits.	Fuite de code, usage non autorisé ou dépendance excessive au modèle.	Définir une politique interne sur les outils, les données autorisées et la traçabilité.

Alors, faut-il auditer son code avec l’IA ?

L’IA appliquée à la cybersécurité ne rend pas les audits humains obsolètes. Elle change surtout l’échelle et la profondeur d’analyse. Claude Mythos illustre ce basculement : repérer des vulnérabilités réelles, suivre des flux complexes, trouver des failles logiques et révéler qu’un bug peut rester caché pendant près de 27 ans. Le bon réflexe n’est pas de déléguer aveuglément la sécurité à un modèle, mais de l’intégrer dans un processus contrôlé : priorisation, vérification, correction, documentation. Le bénéfice pour vous est clair : détecter plus tôt les failles sérieuses et réduire le risque avant qu’un attaquant ne le fasse.

FAQ

• Qu’est-ce qu’une vulnérabilité zero-day ?
  Une vulnérabilité zero-day est une faille inconnue, non corrigée ou non documentée publiquement au moment où elle peut être exploitée. Elle est dangereuse parce que les équipes n’ont pas encore de correctif, de règle de détection fiable ou de procédure standard pour s’en protéger.
• Pourquoi l’IA trouve-t-elle des failles que les scanners ratent ?
  Les scanners classiques repèrent surtout des motifs connus, des signatures ou des règles prédéfinies. Un modèle d’IA peut aller plus loin en analysant le contexte, les flux de données et les enchaînements logiques entre plusieurs fonctions. C’est utile pour détecter des failles qui ne ressemblent pas à un pattern évident.
• Claude Mythos remplace-t-il un audit de sécurité humain ?
  Non. Il peut accélérer l’analyse et faire remonter des pistes intéressantes, mais une faille doit être reproduite, qualifiée et corrigée par des experts. L’IA aide à chercher plus large et plus vite ; la validation humaine reste indispensable pour éviter les faux positifs et prioriser correctement les risques.
• Pourquoi la faille OpenBSD est-elle importante ?
  Elle est importante parce qu’elle montre qu’une vulnérabilité peut rester présente pendant environ 27 ans, même dans un projet reconnu pour son exigence en matière de sécurité. Ce cas rappelle que le code ancien, stable ou rarement modifié mérite aussi d’être audité.
• Comment une entreprise peut-elle utiliser l’IA en cybersécurité sans prendre trop de risques ?
  Elle doit commencer par les dépôts critiques, encadrer les analyses IA, interdire la diffusion de données sensibles non maîtrisées, vérifier chaque alerte, documenter les preuves et intégrer les corrections dans son processus AppSec. L’objectif n’est pas d’automatiser aveuglément, mais d’améliorer la couverture d’audit.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation no/low code avec n8n, l’intégration de l’IA et les sujets SEO/GEO. J’ai travaillé avec des organisations comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer l’usage de l’IA, automatiser vos processus ou fiabiliser vos données business, contactez-moi.