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

L’IA en cybersécurité peut repérer des vulnérabilités que l’audit humain laisse passer, surtout dans de grands codes anciens. Le cas Claude Mythos montre l’intérêt, mais aussi le risque : les mêmes capacités peuvent aider les défenseurs ou accélérer les attaquants.

Que change l’IA dans l’audit de code ?

L’IA change l’audit de code parce qu’elle peut lire de très grands volumes de code, conserver du contexte sur plusieurs fichiers et raisonner sur l’intention probable du programme, pas seulement chercher des signatures déjà connues.

Un LLM, pour Large Language Model, est un modèle entraîné à comprendre et générer du texte. Appliqué au code source, il peut résumer une fonction, suivre un flux de données, repérer une incohérence entre ce que le code semble vouloir faire et ce qu’il fait réellement. Claude entre dans cette famille de modèles. Claude Mythos, présenté comme une initiative de recherche en sécurité, teste justement la capacité d’un modèle à identifier des vulnérabilités inconnues, dites zero-day, c’est-à-dire non documentées publiquement et non corrigées au moment de leur découverte.

Les méthodes classiques restent indispensables, mais elles n’observent pas toutes le même type de risque.

Revue humaine	Très utile pour comprendre l’architecture, les choix métier et les failles logiques, mais limitée par le temps disponible.
SAST	Le Static Application Security Testing analyse le code sans l’exécuter, souvent avec des règles connues.
Fuzzing	Le fuzzing envoie automatiquement des entrées inattendues à un programme pour provoquer des crashs ou comportements anormaux.
Analyse de dépendances	Elle vérifie si les bibliothèques utilisées contiennent des vulnérabilités déjà référencées.
Scanners de CVE	Les CVE, pour Common Vulnerabilities and Exposures, identifient des vulnérabilités publiques, notamment dans la National Vulnerability Database du NIST.

Le NIST NVD sert de référence pour les vulnérabilités publiées. MITRE CWE classe les catégories d’erreurs logicielles, comme les injections, les débordements mémoire ou les contrôles d’accès incorrects. Google OSS-Fuzz montre aussi que l’automatisation à grande échelle est déjà une pratique reconnue : le projet indique avoir aidé à trouver des dizaines de milliers de bugs dans des logiciels open source.

Le point important n’est donc pas de remplacer les experts sécurité. Le sujet est d’augmenter leur capacité à explorer des zones de code trop vastes, trop anciennes ou trop complexes pour être relues entièrement à la main. Et c’est précisément là que les failles oubliées deviennent intéressantes : certaines survivent pendant des années, malgré les audits, les tests et les scanners.

Pourquoi des failles restent-elles invisibles ?

Des failles restent invisibles parce que les bases de code grossissent, que les équipes priorisent les zones actives, et que le code réputé stable est moins relu. Ce n’est pas un manque de sérieux. C’est un problème d’échelle, de temps et de contexte.

Un système critique accumule souvent des années de compatibilité, de correctifs rapides, de comportements historiques et d’hypothèses implicites. Une fonction écrite il y a quinze ans peut encore fonctionner parfaitement dans les tests habituels, tout en devenant fragile lorsqu’elle interagit avec un nouveau compilateur, une option de configuration rare ou une chaîne d’appels jamais rejouée en audit manuel.

Un audit humain ne peut pas examiner chaque chemin d’exécution avec la même profondeur. Un chemin d’exécution, c’est la suite précise d’instructions suivie par un programme selon les entrées, les types de données, l’état interne et la configuration. Quand une vulnérabilité dépend d’un enchaînement rare, elle peut rester invisible même dans un code relu plusieurs fois.

Le cas d’OpenBSD est symboliquement fort. Une vulnérabilité ancienne, présente pendant environ 27 ans, a été identifiée grâce à une analyse assistée par IA. Il faut rester prudent : l’intérêt n’est pas de détailler une exploitation opérationnelle, mais de comprendre pourquoi cet exemple compte. OpenBSD est justement connu pour sa culture d’audit et sa communication historique sur le faible nombre de failles distantes dans l’installation par défaut. Sa page sécurité officielle en garde la trace : https://www.openbsd.org/security.html.

Ce cas rappelle deux limites humaines. La première est le biais envers le code ancien : s’il n’a pas cassé depuis longtemps, il inspire confiance. La seconde est la difficulté de raisonner globalement sur un logiciel complet. Un bug visible localement saute aux yeux dans une fonction : mauvais calcul, pointeur nul, condition inversée. Une vulnérabilité logique globale apparaît seulement quand plusieurs morceaux corrects séparément produisent ensemble un comportement dangereux.

Les classes de faiblesses se répètent d’ailleurs beaucoup. Le MITRE CWE Top 25 recense chaque année les erreurs logicielles les plus risquées, comme les débordements mémoire, les validations d’entrée insuffisantes ou les contrôles d’accès incorrects : https://cwe.mitre.org/top25/. Google indique aussi qu’OSS-Fuzz a permis de détecter plus de 10 000 vulnérabilités et 36 000 bugs dans l’écosystème open source : https://google.github.io/oss-fuzz/.

Problème d’échelle	Les bases de code deviennent trop grandes pour être relues intégralement avec la même attention.
Problème de contexte	La faille dépend parfois d’un enchaînement rare d’appels, d’états, de types ou de configurations.
Problème d’hypothèse ancienne	Le code stable est souvent moins questionné, alors que son environnement a changé.

Comment un LLM repère-t-il une chaîne faible ?

Un LLM repère une chaîne faible en suivant le sens du code, les flux de données et les dépendances entre fonctions sur une fenêtre de contexte plus large qu’une lecture locale. Il ne cherche pas seulement une règle du type “cette fonction est dangereuse”. Il tente de comprendre ce que le programme fait, quelles données entrent, comment elles sont transformées, validées ou non, puis utilisées.

Un flux de données décrit le trajet d’une valeur depuis son entrée jusqu’à son usage. Une chaîne d’appel est la suite de fonctions traversées. Un état partagé est une variable ou une structure accessible par plusieurs parties du programme. Une conversion de type change la représentation d’une valeur, par exemple d’un entier signé vers un entier non signé. Une précondition est une règle supposée vraie avant d’exécuter une fonction, comme “la taille doit être positive et inférieure à une limite”.

Le point important est simple : une vulnérabilité peut naître trois appels plus tôt. Une donnée peut être validée comme entier signé, puis convertie plus loin en entier non signé, puis utilisée comme taille mémoire ou limite de boucle. Localement, chaque fonction semble raisonnable. Globalement, la chaîne devient fragile.

Fonction lireTaille(entree):
    # Vérification correcte en apparence
    Si entree >= 0 et entree < 1024:
        Retourner entree
    Retourner erreur

Fonction preparerTraitement(tailleSignee):
    # Conversion qui change la sémantique de la valeur
    tailleNonSignee = convertirEnNonSigne(tailleSignee)
    Retourner tailleNonSignee

Fonction traiter(taille):
    # Usage sensible : allocation ou boucle
    Si taille < LIMITE_MAX:
        buffer = allouer(taille)
        Retourner buffer
    Retourner erreur

Un LLM peut signaler l’hypothèse suivante : la validation initiale porte sur une représentation, mais l’usage final dépend d’une autre représentation. Cette intuition ressemble à une revue de code expérimentée, pas à une preuve formelle.

Les limites restent nettes. Un LLM peut halluciner, produire des faux positifs ou manquer une contrainte importante si le contexte fourni est incomplet. Il dépend aussi de la qualité du dépôt, des types, des tests et des conventions métier. Surtout, il ne prouve pas automatiquement l’exploitabilité.

Le SAST, ou analyse statique, inspecte le code sans l’exécuter. Le DAST, ou analyse dynamique, teste l’application en fonctionnement. Le fuzzing envoie beaucoup d’entrées variées pour provoquer des comportements inattendus. L’IA peut suggérer une hypothèse de vulnérabilité, mais la preuve doit passer par des tests, une revue humaine et une reproduction contrôlée.

Capacité du LLM	Bénéfice sécurité	Limite opérationnelle
Suit les flux entre fonctions	Repère des chaînes faibles non visibles localement	Dépend du contexte fourni
Raisonne sur les types et préconditions	Détecte des incohérences de logique	Peut produire des faux positifs
Formule une hypothèse de faille	Accélère la revue humaine	Ne remplace pas les tests ni la preuve contrôlée

Quels risques si les attaquants utilisent ces modèles ?

Le risque principal, c’est l’asymétrie. Une IA ne transforme pas un attaquant moyen en génie de la cybersécurité, mais elle peut réduire le temps nécessaire pour lire du code, formuler des hypothèses de vulnérabilité et prioriser les zones à tester. Ce gain de vitesse compte beaucoup quand une équipe défense doit protéger tout un système, alors qu’un attaquant n’a besoin que d’une faille exploitable.

L’IA en cybersécurité est un outil dual-use, c’est-à-dire utilisable pour défendre comme pour attaquer. Le même modèle peut aider une équipe à corriger plus vite une injection SQL, ou aider un attaquant à chercher plus largement dans un dépôt open source. La menace ne vient donc pas d’une IA magique. Elle vient surtout de l’automatisation d’étapes coûteuses : lecture du code, tri des fichiers, corrélation entre dépendances, génération de tests, rédaction d’un rapport exploitable.

Pour une entreprise, les risques sont très concrets :

• Fuite de code confidentiel : Un développeur peut copier du code sensible dans un outil non maîtrisé, sans savoir où les données sont stockées ni réutilisées.
• Faux sentiment de sécurité : Un scan IA rassurant ne remplace pas une revue de code, des tests de sécurité et une analyse d’architecture.
• Surcharge de faux positifs : Un modèle peut signaler beaucoup de problèmes faibles ou inexistants, ce qui fatigue les équipes et ralentit les vraies corrections.
• Divulgation prématurée : Une faille trouvée trop vite, puis publiée sans coordination, peut exposer les utilisateurs avant qu’un correctif soit prêt.
• Dépendance à des modèles opaques : Un modèle fermé donne rarement une explication complète sur ses données, ses limites et ses biais.

Ce point rejoint la responsible disclosure, ou divulgation coordonnée. Le principe est simple : prévenir les mainteneurs d’un logiciel, leur laisser un délai raisonnable pour corriger, puis publier les détails de manière responsable. C’est une pratique essentielle quand l’IA accélère la découverte de failles.

Les bonnes références existent déjà. Le guide CISA Secure by Design pousse à intégrer la sécurité dès la conception. Le NIST AI Risk Management Framework propose une méthode pour identifier, mesurer et réduire les risques liés à l’intelligence artificielle. L’OWASP Top 10 for Large Language Model Applications liste les risques propres aux applications utilisant des LLM, c’est-à-dire des grands modèles de langage.

Bloquer l’IA n’est pas une stratégie suffisante. Les attaquants l’utiliseront quand même. La réponse sérieuse consiste donc à organiser son usage défensif, avec des règles, des outils validés, des garde-fous et un cadre d’intégration clair.

Comment intégrer l’IA sans fragiliser la sécurité ?

Il faut intégrer l’IA comme un copilote d’audit encadré, jamais comme une autorité finale. Un modèle peut accélérer la lecture du code, repérer des motifs suspects et proposer des pistes, mais il peut aussi halluciner, manquer le contexte métier ou surévaluer une alerte.

La méthode tient en cinq étapes simples.

• 1. Cartographier les dépôts, les langages, les dépendances critiques et les zones sensibles, comme l’authentification, les paiements, les exports de données ou les appels à des API internes.
• 2. Définir les règles d’usage des modèles. Interdire l’envoi de code confidentiel vers un service non validé, et préférer des environnements contrôlés quand le dépôt contient du secret industriel, des données personnelles ou du code propriétaire.
• 3. Combiner plusieurs contrôles. L’IA ne remplace pas le SAST, analyse statique du code, le DAST, test dynamique sur une application en fonctionnement, le fuzzing, qui injecte des entrées imprévues, les tests unitaires, l’analyse de dépendances et la revue humaine.
• 4. Trier les résultats avec une grille de risque. Prendre en compte l’impact, l’exploitabilité, l’exposition, la criticité business et la présence éventuelle dans le catalogue CISA Known Exploited Vulnerabilities, une liste publique de failles déjà exploitées activement.
• 5. Corriger, tester, documenter et alimenter la dette technique de sécurité. Une faille corrigée sans test de non-régression peut revenir au prochain refactoring.

Le CI/CD, pour Continuous Integration et Continuous Delivery, sert à déclencher ces contrôles régulièrement à chaque merge, build ou déploiement. L’intérêt est clair : Passer d’audits ponctuels, souvent trop tardifs, à une sécurité intégrée dans le flux de développement.

Pratique	Objectif	Outil possible	Point de vigilance
Analyse IA du code	Repérer des motifs suspects	Modèle validé en interne	Ne pas exposer de code confidentiel
SAST	Détecter les vulnérabilités dans le code source	Semgrep, SonarQube, CodeQL	Limiter les faux positifs
DAST	Tester l’application en fonctionnement	OWASP ZAP, Burp Suite	Éviter les tests agressifs en production
Analyse des dépendances	Identifier les librairies vulnérables	Dependabot, Snyk, Trivy	Prioriser les failles réellement exposées

Commencer petit reste la meilleure option. Choisir un périmètre limité et mesurable, par exemple un dépôt critique ou une librairie interne, puis élargir seulement après validation du taux de faux positifs et du temps gagné. Vous obtenez une sécurité plus continue, plus vérifiable, moins dépendante de la mémoire des équipes.

Alors comment s’en servir sans ouvrir la porte aux attaquants ?

L’IA ne rend pas la cybersécurité simple, mais elle change l’échelle du travail. Claude Mythos illustre une rupture utile : un modèle peut explorer du code ancien, suivre des chaînes logiques complexes et faire remonter des failles restées invisibles pendant des années. Le revers est évident : ces capacités sont aussi intéressantes pour les attaquants. La bonne réponse consiste à encadrer l’usage, croiser les résultats avec les outils classiques, conserver une validation humaine et industrialiser la correction. Pour vous, le bénéfice est concret : moins d’angles morts, une priorisation plus rapide et une sécurité logicielle plus continue.

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. Le terme indique que les éditeurs et défenseurs disposent de zéro jour d’avance si la faille est exploitée.
• Pourquoi l’IA trouve-t-elle des failles que les humains manquent ?
  Elle peut analyser de très grands volumes de code sans fatigue, conserver davantage de contexte et repérer des relations entre fonctions éloignées. Cela aide surtout pour les failles logiques, qui ne se voient pas toujours dans une lecture locale du code.
• Un LLM remplace-t-il un expert cybersécurité ?
  Non. Un LLM peut accélérer la recherche, proposer des hypothèses et prioriser des zones à vérifier. Mais la validation, la preuve d’impact, la correction et la décision de divulgation doivent rester encadrées par des experts.
• Quels sont les principaux risques de l’IA en cybersécurité ?
  Les risques majeurs sont l’usage par des attaquants, la fuite de code confidentiel vers des outils non maîtrisés, les faux positifs, les hallucinations et le mauvais tri des alertes. L’enjeu est donc autant organisationnel que technique.
• Comment utiliser l’IA pour sécuriser du code en entreprise ?
  Le plus efficace est de l’intégrer à une chaîne existante : revue humaine, SAST, DAST, fuzzing, tests automatisés, analyse de dépendances et CI/CD. L’IA doit servir à accélérer l’analyse et la priorisation, pas à valider seule la sécurité d’un logiciel.

 

 

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 métiers et le 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 cadrer l’usage de l’IA, automatiser vos contrôles ou fiabiliser vos données business, contactez-moi.