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

Elle peut déjà repérer des vulnérabilités que les audits humains et les scanners classiques laissent passer. L’exemple de Claude Mythos montre pourquoi l’analyse sémantique du code change la recherche de failles, mais aussi pourquoi cette puissance doit être encadrée.

Que change l’IA en cybersécurité ?

L’IA change surtout le niveau de lecture du code. Un scanner classique cherche des signes déjà connus ; un modèle comme Claude peut aussi examiner le contexte, suivre une donnée d’une fonction à l’autre et se demander si le comportement réel du programme correspond à l’intention apparente du développeur.

Claude Mythos est un projet de recherche d’Anthropic qui utilise Claude pour chercher des vulnérabilités dans de vraies bases de code. Une vulnérabilité est une faiblesse exploitable dans un logiciel, par exemple une vérification d’accès absente, une injection SQL ou une mauvaise gestion mémoire. Une zero-day est une vulnérabilité inconnue de l’éditeur, ou connue mais sans correctif disponible, donc exploitable avant défense complète.

La différence importante se joue dans l’analyse. L’analyse statique consiste à examiner le code sans l’exécuter. Les outils traditionnels le font déjà très bien sur des règles précises : “Cette fonction est dangereuse”, “Cette entrée utilisateur arrive dans une requête SQL”, “Ce paramètre n’est pas validé”. Le problème, c’est qu’ils produisent souvent des faux positifs, c’est-à-dire des alertes qui semblent graves mais ne correspondent pas à une faille exploitable.

Un modèle d’IA ajoute du raisonnement sémantique. Le raisonnement sémantique consiste à interpréter le sens du code, pas seulement sa forme. Le modèle peut suivre les flux de données, comprendre les conditions d’exécution, relier plusieurs appels dispersés et repérer un enchaînement risqué qu’une règle isolée ne voit pas. Cela ne veut pas dire qu’il “comprend” comme un auditeur humain, ni qu’il trouve magiquement des zero-days. Cela veut dire qu’il augmente la capacité d’exploration et aide à prioriser les zones suspectes.

Les bonnes pratiques restent les mêmes. Le NIST SP 800-218, Secure Software Development Framework, rappelle l’importance de concevoir, développer, tester et maintenir les logiciels de façon sécurisée : Https://csrc.nist.gov/publications/detail/sp/800-218/final. La CISA maintient aussi le catalogue Known Exploited Vulnerabilities, utile pour traiter d’abord les failles réellement exploitées : Https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

Approche	Force principale	Limite principale
Scanner classique	Détecte vite des patterns, règles et signatures connues.	Rate les chaînes logiques complexes et génère des faux positifs.
Audit humain	Comprend l’architecture, le métier et les scénarios d’attaque.	Coûte cher et ne couvre pas toujours toute la base de code.
Analyse assistée par IA	Explore plus largement le code et priorise les zones suspectes.	Dépend du contexte fourni et doit être vérifiée par un expert.

Pourquoi des failles restent invisibles ?

Une faille ne reste pas cachée parce que les équipes ne savent pas relire du code. Elle reste souvent cachée parce que l’échelle dépasse ce qu’un audit humain peut absorber sérieusement.

Un projet logiciel mature peut contenir des centaines de milliers, parfois plusieurs millions de lignes. Le noyau Linux dépasse 30 millions de lignes selon les comptages régulièrement publiés par la Linux Foundation et les analyses de dépôts. À cette taille, personne ne relit tout, ligne par ligne, à chaque version. Les équipes priorisent ce qui présente le plus de risque immédiat.

En pratique, l’attention se concentre sur quelques zones :

• Le code récemment modifié, parce qu’un changement introduit souvent un bug.
• Les composants exposés à Internet, comme une API, un serveur SSH ou un parseur de fichiers.
• Les alertes connues, remontées par des scanners, des tests ou des rapports de sécurité.
• Les parties critiques, comme l’authentification, la cryptographie ou la gestion mémoire.

Le problème, c’est que le code historique sort facilement du radar. Il fonctionne depuis longtemps, les tests passent, personne ne veut le toucher sans raison. Cette stabilité apparente crée un biais de confiance : si ce code était dangereux, on l’aurait déjà vu. Ce raisonnement est compréhensible, mais faux.

Certaines vulnérabilités n’apparaissent que dans une combinaison très précise. Une entrée particulière, suivie d’un appel de fonction peu courant, dans un état mémoire spécifique, sur un chemin d’exécution rarement emprunté. Un chemin d’exécution désigne simplement la suite réelle d’instructions parcourues par un programme selon les données reçues et les conditions rencontrées. Deux utilisateurs peuvent utiliser le même logiciel pendant des années sans jamais déclencher le mauvais chemin.

L’exemple d’OpenBSD est utile parce qu’il évite les caricatures. OpenBSD est un projet réputé pour son sérieux en sécurité. Pourtant, Qualys a publié en 2019 une analyse de vulnérabilités dans son mécanisme d’authentification, dont CVE-2019-19521, liée à du code présent depuis environ OpenBSD 2.1, en 1997 selon l’avis technique de Qualys. Le point important n’est pas de prétendre qu’OpenBSD serait négligent. C’est l’inverse : même dans un projet très attentif à la sécurité, un bug ancien peut survivre pendant des décennies.

L’ancienneté n’est donc pas une preuve de sûreté. Elle peut même rendre une faille plus invisible, parce que le code inspire confiance, parce que la dette technique décourage les modifications, et parce que les revues humaines restent limitées par la fatigue, le temps et le contexte disponible. C’est précisément sur ces chemins complexes, anciens et peu explorés que des modèles comme Claude changent la façon d’analyser le code.

Comment Claude repère ces vulnérabilités ?

Claude ne repère pas une faille uniquement parce qu’une ligne “a l’air dangereuse”. Il suit plutôt le sens du code : d’où vient une donnée, quelles fonctions la manipulent, quelles hypothèses sont faites sur elle, puis à quel endroit elle peut produire un effet risqué.

Cette approche ressemble à une analyse sémantique, c’est-à-dire une lecture du comportement réel du programme, pas seulement de sa syntaxe. Une variable peut sembler inoffensive dans une fonction, puis devenir critique trois appels plus loin parce qu’elle sert à ouvrir un fichier, construire une requête SQL, générer du HTML ou décider si un utilisateur a le droit d’accéder à une ressource.

Source	Point d’entrée d’une donnée, par exemple un formulaire, une URL, un cookie ou une API.
Sink	Point sensible où la donnée produit un effet, comme lire un fichier, exécuter une commande ou afficher du HTML.
Propagation	Chemin suivi par la donnée entre plusieurs variables, fonctions ou objets.
Validation d’entrée	Vérification qu’une donnée respecte un format attendu avant d’être utilisée.
Contrôle d’accès	Vérification qu’un utilisateur a bien le droit d’effectuer une action ou de consulter une ressource.
Dépassement de tampon	Erreur où un programme écrit plus de données que la zone mémoire prévue ne peut en contenir.
Bug logique	Erreur de raisonnement dans le fonctionnement du programme, même si le code ne plante pas.

Voici un exemple défensif et volontairement simplifié. Il ne donne aucune procédure d’exploitation, il montre seulement comment une donnée insuffisamment validée traverse plusieurs fonctions avant d’arriver dans un point sensible.

Function RecupererNomDocument(Requete) {
    Nom = Requete.Parametre("document")
    Si Nom.EstVide() Alors Retourner "profil_public.html"
    Retourner Nom
}

Function ConstruireChemin(Nom) {
    Chemin = "/documents_autorises/" + Nom
    Retourner Chemin
}

Function AfficherDocument(Requete, Utilisateur) {
    Nom = RecupererNomDocument(Requete)
    Chemin = ConstruireChemin(Nom)

    Si Utilisateur.EstConnecte() Alors
        Contenu = LireFichier(Chemin)
        Afficher(Contenu)
    FinSi
}

Le problème ne tient pas à une ligne spectaculaire. La source est le paramètre “document”. La donnée est propagée dans deux fonctions. La validation vérifie seulement que le champ n’est pas vide. Le contrôle d’accès vérifie que l’utilisateur est connecté, mais pas qu’il a le droit de lire ce document précis. Le sink est LireFichier, car le programme utilise alors la donnée pour accéder au système de fichiers.

C’est exactement là que l’IA apporte quelque chose : une meilleure couverture du code, une mémoire contextuelle plus large qu’une revue humaine rapide, et une capacité à corréler des détails dispersés. Mais le verdict final doit rester humain. Une IA peut signaler une chaîne suspecte, pas remplacer l’analyse métier, la reproduction contrôlée et la correction validée par l’équipe.

Pourquoi le cas OpenBSD compte ?

Un bug ancien trouvé dans OpenBSD attire forcément l’attention, parce que ce projet n’est pas un logiciel quelconque. OpenBSD fait partie des systèmes open source les plus associés à l’audit de code, à la sécurité par conception et à une culture d’ingénierie très stricte.

La présence d’une faille depuis environ 1997 ne dit pas que le projet serait négligent. Elle rappelle plutôt une réalité moins confortable : même un code relu, stable et maintenu par des équipes exigeantes ne peut pas garantir une absence totale de vulnérabilités. La sécurité n’est pas un état définitif. C’est une réévaluation permanente, avec les outils disponibles à un moment donné.

Pour une DSI, un RSSI, une équipe DevSecOps ou un CTO, le message est clair. Un composant ancien, réputé fiable ou rarement modifié, ne doit pas sortir du radar. Justement parce qu’il bouge peu, il peut être moins souvent questionné. Les bibliothèques héritées, les dépendances open source profondes et les modules “historiques” restent dans la surface d’attaque logicielle, c’est-à-dire l’ensemble des points par lesquels un attaquant peut interagir avec un système.

L’IA change ici les hypothèses de défense. Ce qui était trop coûteux à auditer manuellement, ligne par ligne, peut devenir plus accessible à grande échelle. Un modèle d’analyse peut aider à repérer des chemins d’exécution rares, des comportements incohérents ou des motifs de vulnérabilités déjà connus. Cela ne remplace pas l’expertise humaine, mais cela modifie le rapport coût/bénéfice de l’audit.

Cette logique rejoint les recommandations du NIST SSDF SP 800-218, qui structurent les bonnes pratiques de sécurisation du cycle de développement logiciel, et la base CVE du programme MITRE, qui sert de référence publique pour identifier et suivre les vulnérabilités connues.

Sujet	Enseignement pratique
Code ancien	Réévaluer régulièrement les composants stables, même s’ils n’ont pas changé depuis longtemps.
Dépendances open source	Cartographier les bibliothèques utilisées et surveiller leurs vulnérabilités via CVE.
DevSecOps	Intégrer l’analyse automatisée et l’audit humain dans le cycle de développement.
Gouvernance sécurité	Aligner les pratiques internes avec le NIST SSDF SP 800-218.
IA	Utiliser l’IA pour élargir la couverture d’analyse, sans lui déléguer la décision finale.

Comment utiliser cette IA sans danger ?

L’IA en cybersécurité doit rester un accélérateur défensif, pas une machine autonome à chercher des failles partout. Je la vois comme un assistant capable de lire beaucoup de code, de repérer des motifs suspects et de proposer des pistes, mais jamais comme une autorité finale.

Le point sensible, c’est son caractère dual-use. Un même modèle peut aider une équipe à trouver une injection SQL dans une application interne, mais aussi aider un attaquant à automatiser la recherche de failles sur des cibles non autorisées. Le garde-fou principal est donc simple : Un périmètre légal clair. Les analyses doivent porter uniquement sur du code, des systèmes et des environnements explicitement autorisés.

Quelques règles rendent l’usage beaucoup plus sain :

• Journaliser les analyses : Conserver qui a lancé l’analyse, sur quel dépôt, avec quel outil, à quelle date et avec quels résultats.
• Imposer une revue humaine : Vérifier chaque alerte avant de créer un ticket de sécurité ou une correction.
• Trier les faux positifs : Une IA peut signaler du bruit, surtout sur du code complexe ou ancien.
• Reproduire en environnement contrôlé : Valider la faille sur un environnement de test, jamais directement en production.
• Corriger puis tester : Ajouter des tests de non-régression pour éviter que la faille réapparaisse plus tard.
• Prévoir une divulgation coordonnée : Si la faille concerne un tiers, suivre un processus responsable avant toute publication.

Une approche opérationnelle en entreprise peut tenir en cinq étapes.

• Cartographier les dépôts critiques : Identifier les applications exposées à Internet, les services manipulant des données sensibles et les dépendances à risque.
• Lancer l’analyse IA sur les zones prioritaires : Commencer par les composants les plus exposés, pas par tout le système d’un coup.
• Qualifier les vulnérabilités : Évaluer l’impact, l’exploitabilité et la présence éventuelle dans le catalogue CISA Known Exploited Vulnerabilities, qui recense des failles déjà exploitées activement.
• Corriger dans le pipeline CI/CD : Intégrer les contrôles dans l’intégration continue et le déploiement continu, c’est-à-dire les étapes automatisées qui testent, construisent et déploient le logiciel.
• Mesurer le délai moyen de correction : Suivre le temps entre la détection et la mise en production du correctif.

Les bons repères existent déjà. Le NIST SSDF, pour Secure Software Development Framework, donne un cadre de développement logiciel sécurisé. L’OWASP fournit des listes de risques applicatifs très utilisées, comme l’OWASP Top 10. La CISA aide à prioriser les vulnérabilités réellement exploitées. L’IA ne remplace pas cette gouvernance sécurité. Elle rend surtout le manque de gouvernance plus visible.

Alors, faut-il confier vos audits de code à l’IA ?

L’IA en cybersécurité devient sérieuse quand elle analyse le code au-delà des signatures connues. Claude Mythos illustre ce basculement avec la découverte de vulnérabilités zero-day, dont un bug ancien dans OpenBSD. Le vrai sujet n’est pas de remplacer les experts, mais d’augmenter leur couverture, leur vitesse et leur capacité à relier des chemins d’exécution complexes. La contrepartie est claire, ces outils doivent être encadrés, validés et intégrés à une démarche DevSecOps solide. Pour vous, le bénéfice est concret : mieux prioriser les risques, corriger plus tôt et réduire les angles morts de votre sécurité logicielle.

FAQ

• Qu’est-ce que Claude Mythos ?
  Claude Mythos est un projet de recherche en sécurité mené autour du modèle Claude pour tester sa capacité à analyser du code source et identifier des vulnérabilités. Son intérêt vient de son approche sémantique, plus proche d’un raisonnement sur le comportement du code que d’une simple recherche de signatures.
• Pourquoi parle-t-on de vulnérabilités zero-day ?
  Une vulnérabilité zero-day est une faille inconnue publiquement ou non encore corrigée au moment de sa découverte. Dans ce contexte, l’enjeu est fort, car l’IA peut révéler des failles présentes dans du code réel avant qu’elles soient documentées dans les bases publiques comme CVE.
• L’IA peut-elle remplacer les auditeurs sécurité ?
  Elle ne les remplace pas. Elle accélère l’analyse, élargit la couverture et aide à repérer des chaînes d’exécution complexes. Mais les résultats doivent être validés par des experts, car il faut confirmer l’impact réel, éviter les faux positifs et décider des corrections prioritaires.
• Pourquoi la faille trouvée dans OpenBSD est-elle importante ?
  Elle est importante parce qu’OpenBSD est réputé pour son niveau d’exigence en sécurité. Le fait qu’un bug ancien ait pu rester présent environ 27 ans montre que même les projets les plus rigoureux peuvent contenir des angles morts, surtout dans du code historique considéré comme stable.
• Comment une entreprise peut-elle utiliser l’IA en cybersécurité ?
  Une entreprise peut l’utiliser pour analyser ses dépôts critiques, prioriser les zones à risque, détecter plus tôt des vulnérabilités et renforcer ses revues de code. La bonne approche consiste à l’intégrer dans un cadre DevSecOps, avec validation humaine, tests de non-régression et processus de divulgation responsable.

 

 

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 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é pour des acteurs 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 process data, automatisation ou sécurité applicative avec une approche concrète et maîtrisée, contactez-moi.