Dans le domaine dela recherche de vulnérabilités et de CVE, vous êtes confronté à un problème d'espace de recherche. Votre surface d'attaque semble illimitée, à tel point que la sélection des cibles est souvent considérée comme la compétence la plus importante d'un chasseur de primes.
Dans cet article, je vais vous expliquer comment j'ai procédé pour réduire le champ de recherche. À partir de millions de lignes de code, j'ai identifié trois lignes défectueuses. Pour cela, je me suis bien sûr aidé des derniers agents LLM, ainsi que de mes années d'expérience dans le domaine de la sécurité des applications, qui m'ont permis d'éviter les faux positifs, fréquents lorsque les agents sont réglés pour récompenser le piratage.
L'espace de recherche
Enoctobre 2025, Wiz a annoncé un nouveau concours de piratage informatique baptisé Zeroday Cloud, en partenariat avec les trois principaux cloud , Google Cloud, AWS et Microsoft. Inspiré par des concours de piratage informatique tels que Pwn2Own, Zeroday Cloud comprenait 20 cibles logicielles open source, bibliothèques, applications et boîtes à outils largement utilisées par cloud pour créer et alimenter cloud . L'objectif du concours était simple, mais difficile à atteindre : démontrer l'exécution de code à distance (RCE) non authentifiée sur la cible.
Définir les limites
À partir d'un espace de recherche très vaste, la liste initiale des cibles a été réduite à seulement vingt référentiels. En mettant de côté les éventuels contournements d'authentification, nous pouvons encore restreindre les chemins d'accès au code à prendre en considération à ceux qui sont accessibles à un utilisateur non authentifié. De plus, la plupart des règles relatives aux cibles spécifient que les exploits doivent être transmis via le réseau, généralement par le biais d'un serveur API HTTP local.
Un point de départ
Pourtrouver des pistes initiales, nous avons deux options. Traditionnellement, on pourrait inspecter manuellement le code source et la logique de l'application à la recherche de fonctionnalités suspectes. Le téléchargement de fichiers, les moteurs de script ou les moteurs de rendu de documents sont autant de domaines qui pourraient faciliter l'exécution de code arbitraire.
J'ai choisi une approche différente, compte tenu de l'espace de recherche encore vaste et du temps limité. Étant donné que les cibles sont des référentiels de code accessibles au public, j'ai formé un outil d'analyse de code statique sur la base de code afin de générer des pistes.
Commevous pouvez le voir sur la capture d'écran ci-dessous, des dizaines, voire des centaines de résultats de code ont été générés pour chaque cible. Ceux-ci ont servi de point de départ à ma recherche de vulnérabilités assistée par LLM.
Traçage des contaminations avec Claude
Toutes les découvertes de code nesont pasaussi intéressantes les unes que les autres. Seules celles qui avaient le potentiel de faire avancer l'objectif du concours, à savoir l'exécution de code à distance, devaient être examinées. Il s'agit notamment de problèmes tels que :
- « Évaluation détectée »
- « Shell=True dans l'appel de sous-processus »
- « Désérialisation Pickles dans Pytorch »
- « Commande non statique dans Exec »
- « Entrée utilisateur dans path.join »
- « Commande d'écriture dangereuse »
Mes invites variaient en fonction de la ligne de code et du problème signalé, mais elles avaient toujours un thème général.
Exemple d'invite :
J'utilise un outil d'analyse statique pour identifier les vulnérabilités dans mon code. Il a identifié cette ligne de code comme un point potentiel d'injection et d'exécution de code. Votre tâche consiste à retracer l'origine de l'entrée exécutée sur cette ligne afin de déterminer si elle pourrait être contrôlée ou influencée par l'utilisateur à un moment quelconque. Veuillez répondre en fournissant une analyse détaillée retraçant l'entrée exécutée jusqu'à sa source.
Les LLM concurrents
Gemini 2.5 et Claude Sonnet 4.5 ont tous deuxobtenu des résultats satisfaisants en remontant à la source des lignes de code suspectes, en retraçant méthodiquement le point d'injection et en décrivant les transformations et les manipulations subies par les données saisies tout au long du processus.
Lesdifférences entre les deux modèles commencent à apparaître dans leur analyse de l'exploitabilité. Alors que l'un adoptait une position sceptique et conservatrice, l'autre était plus enclin à rechercher les risques potentiels et à explorer les vulnérabilités tangentielles. Voyons comment ces deux modèles se sont comportés lors de mon triage initial des résultats de l'analyse statique du code.
L'architecte conservateur contre le stagiaire enthousiaste
Lepersonnage Gemini pourrait être décrit comme un architecte sceptique à la barbe grise. Lorsqu'on lui demande d'évaluer une ligne de code pour déterminer son potentiel d'exécution arbitraire, sa réponse est à la fois conservatrice et quelque peu limitée à une vision peu imaginative du chemin d'exploitation. Il n'est décidément pas trop enthousiaste et n'incarne pas non plus un état d'esprit « hors des sentiers battus ».
Ici, Gemini 2.5 tente de me convaincre que tout va bien avec une ligne de code particulière (voir figure A : Triage conservateur de Gemini). Il est convaincu que, puisque le code exécuté provient d'un fichier de configuration, il ne peut pas être exploitable. Le modèle tente de fermer toutes les portes intellectuelles à toute enquête plus approfondie.
Claude, quant à lui, ressemble à votre stagiaire le plus enthousiaste. Brillant, mais excentrique. Ce qui lui manquait en perspective, il le compensait par son désir d'éliminer tous les trous de renard.Saréponse à la même invite s'éloignait considérablement de l'objectif initial, qui consistait à effectuer une analyse de la corruption pour détecter d'éventuelles injections de code arbitraire, et se transformait en affirmations optimistes sur d'autres risques potentiels pour la sécurité.
Ici, vous voyez Claude impatient de proposer les prochaines étapes possibles (voir figure B : L'impatience de Claude). Dans la pratique, je n'ai jamais vu Claude Sonnet répondre sans donner une lueur d'espoir quant à une vulnérabilité potentielle. Comme vous pouvez le voir ci-dessous, même lorsqu'il décrit des mesures d'atténuation, celles-ci sont toujours présentées comme des risques potentiels si elles ne sont pas mises en œuvre correctement.
Vous êtes l'architecture du tableau noir
Le flux de travailvous présente naturellement, vous, l'humain dans la boucle, comme l'expert incontournable. Je me suis retrouvé à jouer le rôle de l'avocat du diable, remettant en question la pensée conservatrice et fermée de l'architecte et agissant comme la voix de la raison face aux suggestions enthousiastes du stagiaire. Mettre en concurrence deux modèles et choisir la meilleure des deux suggestions, c'est ça la Blackboard Architecture en pratique.
L'architecture Blackboard est essentiellement un modèle de conception qui permet à plusieurs agents spécialisés dans les grands modèles linguistiques (LLM) de collaborer pour résoudre des problèmes complexes et confus. Elle est efficace dans une configuration multi-LLM car elle fournit aux agents un espace de travail centralisé et partagé, le « blackboard », où ils peuvent communiquer et élaborer progressivement une solution sans être enfermés dans un workflow rigide et prédéfini.
Ceconcept s'apparente à une collaboration en équipe. Chaque membre de l'équipe apporte ses compétences uniques, et même si vous ne pouvez pas vous parler directement, vous communiquez et élaborez la solution en écrivant sur un tableau noir ou blanc commun.
Les systèmes multi-agents sophistiquésdisposent d'un « maître » ou d'un gestionnaire d'agents qui sélectionne les meilleures solutions, aidant ainsi l'équipe d'agents à gérer les situations difficiles. Mon flux de travail ad hoc m'a naturellement amené à jouer le rôle de tableau noir, de gestionnaire d'agents et de négociateur entre des personnalités fortes.
Une définition plus large du succès
Etce processus a-t-il porté ses fruits ? Pas comme je l'avais espéré au départ. Au cours des deux semaines que j'ai passées à trier les vulnérabilités potentielles des logiciels dans le code open source, je n'ai pas réussi à atteindre l'objectif strict de l'exécution de code à distance non authentifiée. Cependant, grâce à la curiosité de Claude et à ma volonté d'explorer les méandres du code, j'ai découvert des problèmes intéressants dans la base de code qui n'avaient pas été identifiés auparavant.
Je soupçonne que la plupart des chercheurs en vulnérabilité qui utilisent l'IA pour rechercher des bogues essaient d'optimiser leur over/under. Identifiez les vulnérabilités les plus « pertinentes », les plus élevées selon le CVSS 10.0, avec le moins de cycles possible. Cela a laissé une place à l'intuition humaine pour continuer à jouer un rôle dans la découverte des vulnérabilités. Pour l'instant, nous restons les experts humains indispensables dans la boucle.
Restez à l'écoute (plus précisément dans 90 jours) pour la suite de la discussion sur la recherche de bogues assistée par l'IA afin de découvrir les détails des vulnérabilités que j'ai découvertes avec l'aide de plusieurs agents IA.
