IA cybersécurité quel risque pour le code ?

Le risque principal est double : l’IA peut trouver des failles que les humains ratent, mais elle peut aussi industrialiser leur découverte. L’enjeu n’est plus seulement de mieux auditer le code, mais de savoir qui utilise ces capacités, avec quelles limites et quels contrôles.

Pourquoi une IA trouve des failles oubliées ?

Une IA trouve des failles oubliées parce qu’elle peut analyser de très grands volumes de code, suivre des chemins d’exécution longs et repérer des incohérences logiques que les audits humains priorisent rarement.

Un cas OpenBSD l’illustre bien. Une vulnérabilité serait restée environ 27 ans dans ce projet, pourtant connu pour sa culture sécurité, ses revues de code et sa documentation stricte. Ce n’est pas une preuve de négligence. C’est surtout le signe qu’une faille peut naître d’un détail ancien, d’une dépendance historique ou d’une combinaison très rare entre plusieurs morceaux de code.

Une base de code, c’est l’ensemble du code source d’un logiciel. Dans un système comme OpenBSD, elle évolue pendant des décennies, avec des corrections, des réécritures partielles et des choix de compatibilité. Un chemin d’exécution désigne la suite d’instructions réellement parcourue quand le programme reçoit une entrée donnée. Certains chemins sont évidents. D’autres ne se déclenchent qu’avec un état précis, une option peu utilisée ou une donnée mal formée.

Un audit de sécurité est une revue organisée pour trouver des vulnérabilités dans le code, l’architecture ou la configuration. Même bien mené, il reste contraint par le temps, le budget et l’attention humaine. Un zero-day est une faille inconnue de l’éditeur ou non corrigée au moment où elle est découverte, parfois déjà exploitable avant qu’un correctif existe.

L’échelle complique tout. Les logiciels modernes reposent sur des millions de lignes de code, des bibliothèques tierces et des dépendances open source. MITRE maintient les bases CVE, qui identifient les vulnérabilités publiques, et CWE, qui classe les types de faiblesses logicielles. Le NIST SP 800-218 décrit des pratiques de développement sécurisé avec son cadre SSDF, pour “Secure Software Development Framework”. Google OSS-Fuzz montre aussi l’intérêt des analyses automatisées à grande échelle : le projet indique avoir aidé à corriger plus de 10 000 vulnérabilités et 36 000 bugs dans des projets open source.

Problème	Limite humaine	Apport de l’IA
Code ancien	Contexte difficile à reconstruire après des années	Analyse rapide de grands historiques et de nombreuses variantes
Chemins d’exécution rares	Tests manuels centrés sur les cas probables	Exploration massive de scénarios inhabituels
Dépendances multiples	Vision partielle des interactions entre composants	Détection d’incohérences entre bibliothèques, appels et données

Que change Claude Mythos dans l’audit ?

Claude Mythos change l’audit parce qu’il ne se limite pas à chercher des motifs connus, il tente de comprendre le sens du code et les relations entre fonctions.

Claude Mythos désigne une initiative de recherche en sécurité d’Anthropic qui utilise Claude pour analyser des bases de code et identifier des vulnérabilités non documentées. L’idée n’est pas seulement de scanner des fichiers, mais de raisonner sur ce que le programme autorise, bloque, transforme ou oublie de vérifier.

Une analyse statique classique inspecte le code sans l’exécuter. Elle repère par exemple une fonction dangereuse, une variable non initialisée ou une mauvaise configuration. Une recherche par signatures va plus loin dans l’automatisation, mais reste dépendante de schémas déjà connus : une forme de bug, une séquence d’instructions, une empreinte de vulnérabilité. C’est utile, rapide, mais limité face aux erreurs inédites.

Une analyse sémantique cherche autre chose : comprendre ce que le code fait réellement. Cela implique de suivre les appels de fonctions, les flux de données, les conditions d’entrée et les erreurs de logique. Par exemple, une variable peut être validée dans une fonction, modifiée dans une autre, puis utilisée dans un contexte sensible sans nouvelle vérification. Ce type de faille ne ressemble pas toujours à une signature connue.

• Outil traditionnel : Il applique des règles explicites sur le code. Il est efficace pour les erreurs connues, mais peut manquer une faille qui dépend du contexte métier.
• Fuzzing : Il exécute le programme avec beaucoup d’entrées générées automatiquement pour provoquer des crashs ou comportements anormaux. Google OSS-Fuzz applique ce principe en continu sur des projets open source.
• IA de raisonnement : Elle tente de relier plusieurs morceaux de code pour formuler une hypothèse de vulnérabilité. Elle peut aider à explorer des chemins complexes, mais elle peut aussi se tromper.

Le vrai intérêt se situe donc dans la complémentarité. La DARPA Cyber Grand Challenge a montré dès 2016 que l’automatisation pouvait découvrir et exploiter certaines failles sans intervention humaine directe. OWASP reste une référence utile pour qualifier les risques applicatifs, comme les contrôles d’accès cassés ou les injections.

Reste un point non négociable : un résultat produit par IA doit être reproduit, qualifié et corrigé par des experts. Une alerte n’est pas une preuve. Une explication plausible n’est pas un correctif.

Pourquoi les humains ratent ces vulnérabilités ?

Les humains ratent ces vulnérabilités parce que leur attention est limitée, que les bases de code sont trop vastes et que certaines failles n’apparaissent que dans des enchaînements précis. Même un bon auditeur ne lit pas un système entier avec le même niveau de profondeur, surtout quand le code évolue vite, dépend de bibliothèques externes et mélange logique métier, réseau, authentification et gestion mémoire.

Le premier problème est un problème d’échelle. Un audit sérieux force à prioriser les zones critiques, les changements récents, les composants exposés à Internet et les parties du code qui ont déjà produit des bugs. Cette priorisation est rationnelle, mais elle crée forcément des angles morts. Une surface d’attaque désigne justement l’ensemble des points par lesquels un attaquant peut interagir avec un système : API, formulaires, fichiers importés, messages réseau, scripts internes ou dépendances tierces.

Le deuxième problème est un problème de contexte. Une faille peut dépendre d’un paramètre mal validé, d’un appel indirect, d’une hypothèse implicite ou d’un état mémoire particulier. Un flux de données décrit le trajet d’une donnée depuis son entrée dans le système jusqu’à son utilisation. Une validation d’entrée consiste à vérifier qu’une donnée reçue respecte les règles attendues avant de l’utiliser. Une vulnérabilité logique apparaît quand le programme fait exactement ce qui est codé, mais pas ce qui était prévu du point de vue sécurité.

int is_valid_user_id(int id) {
    return id > 0 && id < 10000;
}

void load_user(int id) {
    query_database(id);
}

void public_api(int id) {
    if (is_valid_user_id(id)) {
        load_user(id);
    }
}

void internal_job(int id) {
    load_user(id);
}

Cet exemple reste volontairement pédagogique et non exploitable. La validation existe dans public_api, mais un autre chemin d’appel, internal_job, appelle directement la fonction sensible. Le bug ne se voit pas en lisant une seule fonction. Il apparaît quand on suit le chemin complet.

Comme vu précédemment, l’IA ne remplace pas l’auditeur. Elle augmente sa capacité à explorer les chemins faibles, à repérer les incohérences et à proposer des zones de vérification que l’humain n’aurait pas priorisées.

• Cartographier les composants critiques et leurs points d’entrée.
• Automatiser les tests de sécurité sur les chemins fréquents et les chemins rares.
• Documenter les hypothèses de sécurité directement près du code concerné.
• Vérifier les dépendances, leurs versions et leurs vulnérabilités connues.
• Relire les chemins d’erreur, les appels indirects et les traitements internes.

Quel risque pour les entreprises ?

Le risque pour les entreprises est que la découverte de failles devienne plus rapide que leur capacité à corriger, surveiller et prioriser. L’IA ne crée pas ce problème à elle seule, mais elle peut accélérer l’analyse du code, des dépendances et des comportements applicatifs.

Côté défense, c’est utile. Un modèle peut aider à auditer un vieux code difficile à maintenir, résumer une base legacy, repérer des patterns suspects, classer des alertes ou suggérer des tests de sécurité. Il peut aussi aider à comprendre plus vite une vulnérabilité complexe, par exemple dans une chaîne de dépendances open source.

Côté attaque, les mêmes capacités peuvent servir à chercher des failles plus efficacement. Un acteur malveillant peut demander de l’aide pour analyser un bout de code, générer des hypothèses de test ou comprendre une erreur mémoire. Cela ne veut pas dire qu’un modèle fournit automatiquement un exploit fiable, c’est-à-dire un code capable d’exploiter réellement une faille. Mais certaines barrières baissent, notamment pour l’analyse, la traduction de code et l’automatisation des essais.

Les entreprises doivent donc prioriser. Le catalogue CISA Known Exploited Vulnerabilities recense les failles déjà exploitées dans le monde réel, ce qui en fait une base utile pour décider quoi corriger en premier. Le Verizon Data Breach Investigations Report 2024 indique aussi que l’exploitation de vulnérabilités comme point d’entrée dans les violations a fortement augmenté, avec une hausse de 180 % sur l’année étudiée. Le sujet n’est donc pas théorique.

Un plan d’action réaliste tient en cinq étapes.

• Inventorier le code, les API, les services exposés et les dépendances logicielles, car on ne protège pas ce qu’on ne connaît pas.
• Intégrer des tests de sécurité dans la chaîne CI/CD, c’est-à-dire le pipeline qui construit, teste et déploie automatiquement le logiciel.
• Utiliser l’analyse statique et le fuzzing, une technique qui envoie des entrées aléatoires ou malformées pour provoquer des bugs.
• Faire relire les résultats produits par l’IA par des humains, car un faux positif peut faire perdre du temps et un faux négatif peut coûter cher.
• Formaliser un processus de patch et de divulgation responsable, avec délais, propriétaires et suivi public ou privé selon les cas.

La gouvernance compte autant que l’outillage. Le NIST AI Risk Management Framework aide à cadrer les risques liés à l’IA, tandis que l’OWASP Top 10 for Large Language Model Applications liste les risques propres aux applications basées sur des modèles de langage, comme l’injection de prompt, les fuites de données ou les usages non contrôlés.

Bénéfices	Risques	Garde-fous
Audit plus rapide du code et des dépendances.	Recherche de failles accélérée côté attaquant.	Priorisation avec CISA KEV et scoring métier.
Meilleur tri des alertes et des vulnérabilités.	Faux positifs, faux négatifs et confiance excessive.	Revue humaine obligatoire des résultats IA.
Analyse plus simple du code legacy.	Exposition de code sensible dans des outils externes.	Règles d’usage, cloisonnement et journalisation.

Alors faut-il confier son code à l’IA ?

Confier une partie de l’audit à l’IA devient difficile à ignorer, surtout quand des vulnérabilités anciennes passent sous les radars pendant des années. Mais l’objectif n’est pas de remplacer les équipes sécurité. Le bon modèle consiste à utiliser l’IA pour explorer plus large, détecter plus tôt et prioriser mieux, puis à garder une validation humaine stricte. Claude Mythos illustre un basculement : l’audit de code devient plus sémantique, plus continu et plus industrialisé. Pour votre business, le bénéfice est clair : réduire les angles morts avant qu’ils ne deviennent des incidents coûteux.

FAQ

• Qu’est-ce qu’une vulnérabilité zero-day ?
  Une vulnérabilité zero-day est une faille inconnue de l’éditeur ou non corrigée publiquement. Le terme signifie que les équipes disposent de zéro jour pour se protéger lorsqu’elle devient connue ou exploitée. Dans un audit de code, trouver un zero-day revient à identifier une faiblesse avant qu’un correctif officiel existe.
• Pourquoi l’IA peut-elle détecter des failles que les outils classiques ratent ?
  Les outils classiques cherchent souvent des signatures, des règles ou des motifs déjà connus. Une IA de raisonnement peut aller plus loin en suivant le contexte du code, les flux de données et les enchaînements d’appels. Elle peut donc repérer des vulnérabilités logiques qui ne ressemblent pas exactement à un bug connu.
• L’IA peut-elle remplacer un auditeur cybersécurité ?
  Non. L’IA peut accélérer l’analyse et élargir la couverture, mais ses résultats doivent être vérifiés. Un auditeur doit confirmer la faille, mesurer son impact, éviter les faux positifs, proposer un correctif et gérer la divulgation responsable. Le meilleur usage reste une collaboration entre automatisation et expertise humaine.
• Quel est le risque principal pour les entreprises ?
  Le risque principal est un déséquilibre entre la vitesse de découverte des failles et la capacité de correction. Si les attaquants utilisent l’IA pour analyser du code ou des composants exposés, les entreprises doivent renforcer leur inventaire logiciel, leurs tests automatisés, leur surveillance et leur processus de patch.
• Comment commencer à utiliser l’IA pour sécuriser son code ?
  Je commencerais par un périmètre limité : un dépôt critique, des dépendances sensibles ou du code legacy difficile à auditer. Il faut combiner analyse statique, fuzzing, revue IA, validation humaine et suivi des correctifs. L’IA doit s’insérer dans le cycle de développement, pas devenir un outil isolé sans gouvernance.

 

 

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, le SEO et le GEO. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez intégrer l’IA dans vos processus data, marketing ou sécurité sans perdre le contrôle technique, contactez-moi.