Quand votre agent découvre une vulnérabilité

Nicholas Carlini, chercheur chez Anthropic, a pointé Claude Code vers le code source du noyau Linux et lui a demandé de trouver des vulnérabilités. Le dispositif : un script bash de 10 lignes et un conteneur Docker avec des builds instrumentés par ASAN. Itérer sur les fichiers source, demander au modèle de chercher des bugs, passer au fichier suivant.¹³

Le résultat, tel que détaillé dans le compte-rendu de Michael Lynch :² un débordement de tampon heap exploitable à distance dans le cache de rejeu LOCK de NFSv4, présent depuis mars 2003 — antérieur à Git lui-même. Deux clients NFS coopérants peuvent lire de la mémoire sensible du noyau 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 vulnérabilités du noyau lors du même balayage. Parallèlement, la même méthodologie a produit 122 entrées provoquant des plantages envoyées à Mozilla, dont 22 ont reçu des CVE.³ Il a décrit « plusieurs centaines de plantages » qu’il n’a pas encore eu le temps de valider et signaler.²

Il s’agit de vulnérabilités confirmées, signalées aux mainteneurs, trouvées par un agent utilisant Opus 4.6 — la même classe de modèle que les praticiens utilisent quotidiennement 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.¹

En bref

La méthodologie de Carlini était minimale : itérer sur les fichiers source, demander à Claude de trouver des vulnérabilités dans chacun, vérifier les résultats avec les assertions ASAN. Opus 4.6 a trouvé substantiellement plus de vulnérabilités qu’Opus 4.1 (8 mois plus ancien) ou Sonnet 4.5 (6 mois plus ancien), suggérant qu’un seuil de capacité a été franchi récemment.² Le goulot d’étranglement est désormais la validation humaine, pas la découverte par l’IA. Cela a des implications directes sur la manière dont les praticiens construisent leurs hooks de sécurité, mènent les revues de code et conçoivent l’audit assisté par agents.

Points clés

• Ingénieurs en sécurité : la capacité est réelle et progresse rapidement. Si vous utilisez la revue de code assistée par agent, vos hooks de sécurité PreToolUse sont plus importants que jamais — non pas pour bloquer Claude, mais pour contrôler ce qu’il peut faire avec ce qu’il découvre.
• Constructeurs de harness : le goulot de vérification (« plusieurs centaines de plantages que je n’ai pas validés ») est un problème de harness. Le tri automatisé, la déduplication et la classification par sévérité constituent la prochaine couche d’infrastructure.
• Tous les autres : le même modèle qui introduit des régressions de performance de 446x trouve aussi des bugs que 23 ans de revue humaine ont manqués. Les deux sont vrais simultanément.

La méthodologie

L’approche de Carlini ne nécessitait ni framework de sécurité sur mesure, ni modèle fine-tuné, ni prompts spécialisés. Il l’a décrite comme « un script bash de 10 lignes et un conteneur Docker » :³

1. Compiler la cible avec l’instrumentation ASAN (AddressSanitizer)
2. Itérer sur les fichiers source en utilisant le modèle pour évaluer la pertinence sécuritaire
3. Prompter Claude Code avec un cadrage capture-the-flag pour les fichiers à haute pertinence
4. Exécuter plusieurs passes par cible (5 à 20 selon la base de code)
5. Utiliser des agents de critique automatisés pour vérifier les résultats avant divulgation

Le cadrage capture-the-flag est déterminant. Dire au modèle « ce code contient un bug » active un mode différent de « examine ce code pour détecter d’éventuels problèmes ». Les développeurs ont observé le même schéma dans leur utilisation quotidienne — Claude trouve davantage de problèmes lorsqu’on lui dit qu’un problème existe que lorsqu’on lui demande s’il pourrait y en avoir un.²

Le coût du balayage se mesure en tokens API, pas en personnes-mois. Carlini a trouvé cinq vulnérabilités confirmées du noyau Linux et 22 CVE Firefox en utilisant un CLI d’agent standard.³ Le même outil qui écrit vos tests unitaires et formate vos imports.

Le seuil de capacité

La découverte la plus frappante est 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ébordement de tampon heap et plusieurs vulnérabilités supplémentaires
• Opus 4.1 (8 mois plus tôt) : n’en a trouvé qu’une faible fraction
• Sonnet 4.5 (6 mois plus tôt) : n’en a trouvé qu’une faible fraction

Quelque chose a franchi un seuil entre les générations de modèles. La capacité à maintenir une base de code complexe en contexte, à raisonner sur les flux de données à travers les frontières de fonctions et à identifier des incohérences subtiles dans les spécifications semble avoir émergé plutôt que progressé graduellement.

Carlini l’a affirmé sans détour : « Je n’en ai jamais trouvé un seul de ma vie auparavant. C’est très, très, très difficile à faire. Avec ces modèles de langage, j’en ai tout un tas. »²

Le paradoxe

La même architecture d’agent qui introduit des régressions de performance — 118 fonctions avec des ralentissements de 3x à 446x — trouve aussi des vulnérabilités de sécurité que des décennies de revue par des experts humains ont manquées. Ce sont des aspects complémentaires du même profil de capacité. La recherche de vulnérabilités repose fondamentalement sur la reconnaissance de motifs parmi des classes connues (débordements de tampon, use-after-free, erreurs de signe sur les entiers), ce qui constitue une force des LLM.⁴ L’optimisation de performance exige l’inverse : raisonner sur des contextes d’exécution spécifiques, le comportement du cache et la complexité algorithmique. Le modèle reconnaît un débordement de tampon à travers des millions de lignes de code, mais ne peut pas vous dire qu’une table de hachage est plus lente qu’un tableau trié pour votre schéma d’accès. Construisez votre harness en conséquence — des hooks de sécurité qui signalent les découvertes, des hooks de performance qui mesurent avant de valider.

Le goulot de 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 parce que je ne les ai pas encore validés. »²

Le goulot d’étranglement s’est déplacé de la découverte vers le tri. Trouver des vulnérabilités potentielles est désormais moins coûteux que de confirmer qu’elles sont réelles. Cela crée un nouveau problème d’infrastructure pour les équipes de 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 vulnérabilité potentielle nécessite une preuve de concept, une évaluation d’impact et un processus de divulgation responsable.

Le tri est le chaînon manquant. Classer des centaines de résultats générés par un agent en vulnérabilités réelles, faux positifs et bruit de faible sévérité — c’est le travail qui ne dispose pas encore de bons outils.

C’est le même schéma que l’on observe dans 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 — elle réside dans l’infrastructure qui traite, filtre et achemine la sortie.

Pour les constructeurs de harness, cela signifie que le prochain hook à forte valeur ajoutée n’est pas un scanner de sécurité. C’est un système de tri sécuritaire : déduplication, classification par sévérité, filtrage des faux positifs et génération automatique de preuves de concept. Les hooks de gouvernance qui contrôlent la sortie de l’agent sont plus importants que les capacités de scan elles-mêmes.

Ce que cela signifie pour les praticiens

Si vous exécutez Claude Code sur des bases de code en production, vous utilisez déjà un système capable de trouver de vraies vulnérabilités. La question n’est pas de savoir si la capacité existe — mais si votre harness est conçu pour gérer ce que l’agent découvre.

Trois actions concrètes :

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

#!/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" }]
    }]
  }
}

Il ne s’agit que d’un point de départ, pas d’une solution prête pour la production — vous ajouteriez la déduplication, le filtrage par sévérité et la limitation de débit. Toutefois, le schéma de base correspond à la méthodologie de Carlini : une boucle sur les fichiers avec un prompt ciblé.³

Construisez une infrastructure de tri. Des résultats de vulnérabilités bruts sans classification par sévérité ne sont que du bruit. Si votre agent produit 50 résultats par balayage, vous avez besoin de déduplication automatisée et de scoring de priorité avant qu’un humain ne voie la liste. C’est un problème de harness, pas un problème de modèle.

Acceptez le paradoxe. Le même modèle qui a besoin de garde-fous de performance est véritablement excellent en reconnaissance de motifs de sécurité. Concevez votre harness pour exploiter cette force et compenser cette faiblesse. Des hooks de sécurité qui scannent. Des hooks de performance qui mesurent. Des hooks de qualité qui vérifient. Chacun couvre ce que les autres manquent.

La vulnérabilité du noyau Linux vieille de 23 ans ne se cachait pas. Elle était en pleine vue, 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 ces systèmes font. La leçon n’est pas que les agents sont meilleurs que les humains en sécurité. La leçon est que les agents couvrent une surface différente — et le harness qui orchestre les deux est ce qui rend la combinaison fiable.

Sources

Questions fréquentes

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

La méthodologie est documentée dans l’interview du podcast.³ La boucle principale : compiler avec ASAN, itérer sur les fichiers source, prompter Claude avec un cadrage capture-the-flag, vérifier les résultats. Carlini a rapporté qu’Opus 4.6 trouvait significativement plus de vulnérabilités que les modèles plus anciens — les résultats avec d’autres générations de modèles peuvent varier.

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

Non. Cela signifie que les agents couvrent une surface différente. Les agents excellent dans la reconnaissance de motifs parmi des classes de vulnérabilités connues à travers de grandes bases de code. Les humains excellent dans la compréhension de vecteurs d’attaque inédits, de failles de logique métier et de propriétés de sécurité dépendantes du contexte. La combinaison est plus forte que l’un ou l’autre seul.

Faut-il s’inquiéter que des attaquants utilisent cette capacité ?

Carlini a explicitement averti qu’« une grosse vague arrive ». La même capacité qui aide les défenseurs à trouver des vulnérabilités est accessible aux attaquants. L’asymétrie réside dans le fait que les défenseurs peuvent automatiser le tri et les correctifs, tandis que les attaquants doivent encore développer des exploits — néanmoins, l’écart de découverte se réduit.