Quand votre agent découvre une faille

Nicholas Carlini, chercheur chez Anthropic, a pointé Claude Code sur les sources du noyau Linux en lui demandant d’y chercher des failles. Le dispositif : un script bash de 10 lignes et un conteneur Docker avec des builds instrumentés par ASAN. Parcourir les fichiers source en boucle, demander au modèle de repérer les bugs, passer au fichier suivant.¹³

Le résultat, tel que le détaille le compte rendu de la conférence rédigé par Michael Lynch :² un dépassement de tampon sur le tas exploitable à distance dans le cache de rejeu LOCK de NFSv4, présent depuis mars 2003, soit avant même l’existence de Git. Deux clients NFS qui coopèrent peuvent lire de la mémoire noyau sensible en débordant un tampon de 112 octets avec un identifiant de propriétaire de verrou de 1 024 octets. Carlini a trouvé au moins quatre autres failles du noyau lors du même balayage. En parallèle, la même méthode a produit 122 entrées provoquant un crash, transmises à Mozilla, dont 22 ont donné lieu à des CVE.³ Il évoque « plusieurs centaines de crashs » qu’il n’a pas encore eu le temps de valider et de signaler.²

Carlini a confirmé ces failles et les a signalées aux mainteneurs. Il les a trouvées avec Opus 4.6, la même classe de modèle que les praticiens utilisent au quotidien pour la revue de code, le refactoring et le développement de fonctionnalités. Carlini a présenté ses résultats à la conférence de sécurité IA [un]prompted en avril 2026.¹

Oui, les agents IA sont capables de trouver de vraies failles de sécurité que des experts humains ont manquées pendant des décennies. Un chercheur d’Anthropic s’est servi de Claude Code et d’un script bash de 10 lignes pour découvrir dans le noyau Linux un dépassement de tampon sur le tas exploitable à distance, vieux de 23 ans, et a tiré 22 CVE Firefox de 122 entrées provoquant un crash. La méthode n’exige aucun cadre logiciel sur mesure : parcourir les fichiers source avec des builds instrumentés par ASAN et demander au modèle de trouver les bugs.

En bref

La méthode de Carlini tenait en peu de choses : parcourir les fichiers source, demander à Claude d’y chercher des failles, confirmer les détections à l’aide des assertions ASAN. Opus 4.6 a trouvé nettement plus de failles qu’Opus 4.1 (antérieur de 8 mois) ou Sonnet 4.5 (antérieur de 6 mois), ce qui laisse penser que la capacité a récemment franchi un seuil.² Le goulot d’étranglement se situe désormais du côté de la validation humaine, pas de la découverte par l’IA. Ce basculement a des conséquences directes sur la façon dont les praticiens conçoivent leurs points d’accroche de sécurité, mènent leurs revues de code et envisagent l’audit assisté par agent.

À retenir

• Ingénieurs sécurité : la capacité est bien réelle et progresse vite. Si vous pratiquez la revue de code assistée par agent, vos points d’accroche de sécurité PreToolUse comptent plus que jamais. Non pas pour bloquer Claude, mais pour encadrer ce qu’il peut faire de ses trouvailles.
• Concepteurs de cadres d’agent : le goulot d’étranglement de la vérification (« plusieurs centaines de crashs que je n’ai pas validés ») relève du cadre d’agent. Tri automatisé, déduplication et classement par gravité forment la prochaine couche d’infrastructure.
• Tous les autres : le même modèle qui introduit des régressions de performance d’un facteur 446 trouve aussi des bugs que 23 ans de relecture humaine ont laissés passer. Les deux sont vrais en même temps.

La méthode

L’approche de Carlini n’a demandé ni cadre de sécurité sur mesure, ni modèle affiné, ni prompts spécialisés. Il la décrit comme « un script bash de 10 lignes plus un conteneur Docker » :³

1. Compiler la cible avec l’instrumentation ASAN (AddressSanitizer)
2. Parcourir les fichiers source en utilisant le modèle pour noter leur pertinence en matière de sécurité
3. Solliciter Claude Code avec un cadrage de type capture-the-flag sur les fichiers les plus pertinents
4. Effectuer plusieurs passes par cible (de 5 à 20 selon la base de code)
5. Faire vérifier les trouvailles par des agents critiques automatisés avant divulgation

Le cadrage capture-the-flag n’est pas anodin. Dire au modèle « ce code contient un bug » active un tout autre régime que « relis ce code à la recherche de problèmes ». Les développeurs observent le même phénomène à l’usage quotidien : Claude trouve davantage de problèmes quand vous lui affirmez qu’il en existe un que lorsque vous lui demandez s’il pourrait y en avoir un.²

Le balayage coûte des tokens d’API, pas des mois-personne. Carlini a trouvé cinq failles confirmées dans le noyau Linux et 22 CVE Firefox avec un CLI d’agent grand public.³ Le même outil qui écrit vos tests unitaires et met en forme vos imports.

Le seuil de capacité

Le constat le plus frappant tient à l’écart entre générations de modèles. Carlini a tenté de reproduire ses résultats avec des modèles plus anciens :²

• Opus 4.6 (sorti environ 2 mois avant la conférence) : a trouvé le dépassement de tampon sur le tas ainsi que plusieurs autres failles
• Opus 4.1 (antérieur de 8 mois) : n’en a trouvé qu’une petite fraction
• Sonnet 4.5 (antérieur de 6 mois) : n’en a trouvé qu’une petite fraction

Un seuil a bel et bien été franchi d’une génération de modèles à l’autre. La capacité à tenir une base de code complexe en contexte, à raisonner sur le flux de données au-delà des frontières de fonctions et à repérer de subtils écarts par rapport à la spécification semble avoir émergé d’un coup plutôt que de s’améliorer progressivement.

Carlini le dit sans détour : « Je n’en avais jamais trouvé une seule de ma vie. C’est très, très, très difficile à faire. Avec ces modèles de langage, j’en ai tout un lot. »²

Le paradoxe

L’architecture d’agent qui introduit des régressions de performance — 118 fonctions ralenties d’un facteur 3 à 446 — est aussi celle qui déniche des failles de sécurité que des décennies de relecture experte n’ont pas vues. Ce sont deux facettes complémentaires d’un même profil de capacités. La recherche de failles relève fondamentalement de la reconnaissance de motifs face à des classes connues (dépassements de tampon, use-after-free, problèmes de signe sur les entiers), et c’est précisément là que réside la force d’un LLM.⁴ L’optimisation des performances exige l’inverse : raisonner sur des contextes d’exécution précis, sur le comportement du cache et sur la complexité algorithmique. Le modèle reconnaît un dépassement de tampon au milieu de millions de lignes de code, mais il ne saura pas vous dire qu’une table de hachage est plus lente qu’un tableau trié pour votre schéma d’accès. Concevez votre cadre d’agent en conséquence : des points d’accroche de sécurité qui signalent les trouvailles, des points d’accroche de performance qui mesurent avant de valider.

Le goulot d’étranglement de la vérification

L’aveu le plus révélateur de Carlini : « J’ai tellement de bugs dans le noyau Linux que je ne peux pas les signaler, faute de les avoir validés. »²

Le goulot d’étranglement s’est déplacé vers le tri, et non plus la découverte. Trouver des failles potentielles coûte moins cher que de confirmer leur réalité. Cette inversion crée un nouveau problème d’infrastructure pour les équipes sécurité :

La découverte est automatisée. Un agent peut balayer une base de code en quelques heures.

La vérification est manuelle. Chaque faille potentielle demande une preuve de concept, une évaluation de l’impact et une procédure de divulgation responsable.

Le tri est le maillon manquant. Ranger des centaines de trouvailles produites par un agent entre vraies failles, faux positifs et bruit de faible gravité : voilà le travail qui n’a pas encore d’outillage digne de ce nom.

Le schéma reproduit celui de la revue de code assistée par agent : l’agent produit des résultats bruts plus vite que les humains ne peuvent les évaluer. La valeur ne réside pas dans la génération, mais dans l’infrastructure qui traite, filtre et aiguille ces résultats.

Pour qui construit un cadre d’agent, cela signifie que le prochain point d’accroche à forte valeur n’est pas un outil d’analyse de sécurité. C’est un système de tri des failles : déduplication, classement par gravité, filtrage des faux positifs et génération automatique de preuves de concept. Les points d’accroche de gouvernance qui encadrent la sortie de l’agent comptent davantage que les capacités d’analyse elles-mêmes.

Ce que cela change pour les praticiens

Si vous lancez Claude Code sur des bases de code en production, vous faites déjà tourner un système capable de trouver de vraies failles. La question n’est pas de savoir si la capacité existe, mais si votre cadre d’agent sait absorber ce que l’agent découvre.

Trois gestes concrets :

Ajoutez un balayage de sécurité à votre chaîne de revue. Un point d’accroche PostToolUse sur Write/Edit peut déclencher une analyse de sécurité ciblée sur les fichiers modifiés. Le point d’accroche lit le chemin du fichier depuis stdin (Claude Code transmet le JSON de l’événement aux points d’accroche via stdin) :

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking, runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

Le point d’accroche ci-dessus est un point de départ, pas du code prêt pour la production. Il faudrait y ajouter la déduplication, le filtrage par gravité et une limitation du débit. Mais le principe reste celui de la méthode de Carlini : une boucle sur les fichiers avec un prompt ciblé.³

Bâtissez une infrastructure de tri. Des signalements bruts, sans classement par gravité, ne sont que du bruit. Si votre agent produit 50 trouvailles par balayage, il vous faut une déduplication automatique et un score de priorité avant qu’un humain ne voie la liste. Le goulot d’étranglement relève du cadre d’agent, pas du modèle.

Assumez le paradoxe. Le même modèle qui réclame des garde-fous de performance excelle véritablement dans la reconnaissance de motifs de sécurité. Concevez votre cadre d’agent pour tirer parti de cette force et compenser cette faiblesse. Des points d’accroche de sécurité qui analysent. Des points d’accroche de performance qui mesurent. Des points d’accroche de qualité qui vérifient. Chacun couvre ce que les autres laissent passer.

La faille du noyau Linux vieille de 23 ans ne se cachait pas. Elle était à la vue de tous, dans un fichier que des milliers d’ingénieurs avaient lu. Le modèle l’a trouvée parce que la reconnaissance de motifs à grande échelle est précisément ce que font ces systèmes. La leçon n’est pas que les agents sont meilleurs que les humains en sécurité. La leçon, c’est qu’ils couvrent une autre surface, et que c’est le cadre d’agent qui orchestre les deux qui rend la combinaison fiable.

Mise à jour (7 avril 2026) : Anthropic a annoncé Project Glasswing, un nouveau modèle nommé Claude Mythos qui a porté l’approche de Carlini à l’échelle de milliers de failles zero-day sur toutes les grandes plateformes. Mythos reste réservé à 12 partenaires et n’est pas accessible au public. L’article ci-dessus porte sur la recherche initiale de Carlini ; la suite traite de sa mise en produit.

Sources

Questions fréquentes

Puis-je reproduire l’approche de Carlini avec Claude Code ?

Carlini a documenté sa méthode dans son entretien en podcast.³ La boucle centrale : compiler avec ASAN, parcourir les fichiers source, solliciter Claude avec un cadrage de type capture-the-flag, confirmer les détections. Carlini indique qu’Opus 4.6 a trouvé nettement plus de failles que les modèles plus anciens ; les résultats peuvent donc varier avec d’autres générations de modèles.

Cela signifie-t-il que les agents IA sont meilleurs que les humains pour trouver des failles de sécurité ?

Non. Cela signifie qu’ils couvrent une autre surface. Les agents excellent dans la reconnaissance de motifs face à des classes de failles connues, à l’échelle de vastes bases de code. Les humains excellent dans la compréhension des vecteurs d’attaque inédits, des failles de logique métier et des propriétés de sécurité qui dépendent du contexte. La combinaison des deux est plus forte que chacune isolément.

Faut-il s’inquiéter de l’usage qu’en feront les attaquants ?

Carlini a explicitement mis en garde contre « une grosse vague qui arrive ». La capacité qui aide les défenseurs à trouver des failles est tout aussi accessible aux attaquants. L’asymétrie tient à ceci : les défenseurs peuvent automatiser le tri et l’application des correctifs, tandis que les attaquants doivent encore développer des exploits. Mais l’écart en matière de découverte se resserre.