Ce métier se distingue du pentest par le temps et la profondeur. Le chercheur choisit une cible (un navigateur, un hyperviseur, un noyau, un équipement réseau, une application mobile), en cartographie la surface d'attaque, lance des campagnes de fuzzing, lit le binaire dans IDA Pro, Ghidra ou Binary Ninja, puis évalue si un bug est exploitable malgré les protections du système. Les postes se trouvent chez des cabinets spécialisés, dans des laboratoires de grands groupes, chez les éditeurs et dans des structures liées à la défense, souvent avec habilitation.
Une liste de CVE sur un CV dit peu de choses seule. Certaines viennent d'un fuzzer lancé sans effort sur une cible jamais testée, d'autres de mois de travail. Le candidat raconte l'histoire d'une découverte : pourquoi cette cible, comment le bug a été trouvé, ce qu'il permettait, comment l'éditeur a été prévenu. Les profils solides parlent aussi de leurs échecs, des pistes abandonnées après trois semaines.
Les questions restent au niveau de la méthode, des familles de bugs et des protections. Un exploit ne se juge pas ligne par ligne dans un premier entretien, et un manager technique le fera mieux sur un exercice en direct. Le PDF ajoute un cas de 20 minutes et une grille de 1 à 4.
Outils et notions du chercheur en vulnérabilités
IDA Pro, Ghidra, Binary Ninja
Les désassembleurs et décompilateurs qui transforment un binaire en code lisible. IDA Pro est commercial, Ghidra est publié en open source par la NSA, Binary Ninja est apprécié pour son API. Le choix importe peu : la question porte plutôt sur la façon dont la personne automatise ses analyses avec des scripts.
Fuzzers : AFL++, libFuzzer, syzkaller
Des outils qui envoient des entrées générées en masse à un programme et repèrent les plantages. AFL++ et libFuzzer guident la génération par la couverture de code, syzkaller vise les appels système du noyau. Le savoir-faire tient dans le harnais, ce petit programme qui relie le fuzzer à la fonction ciblée, et dans le suivi de la couverture.
Sanitizers
AddressSanitizer, UndefinedBehaviorSanitizer ou MemorySanitizer instrumentent le programme pour signaler une corruption mémoire au moment où elle se produit. Couplés au fuzzing, ils transforment un comportement silencieux en rapport précis. Un candidat qui fuzz sans eux passe à côté de nombreux bugs.
Diffing de correctifs
BinDiff ou Diaphora comparent deux versions d'un binaire pour voir ce qu'un correctif a modifié. Le chercheur s'en sert pour comprendre une vulnérabilité corrigée sans détails publics, vérifier que le correctif est complet ou trouver des variantes du même bug.
CodeQL et analyse de variantes
Quand le code source est disponible, CodeQL ou Semgrep permettent d'écrire une requête qui décrit un motif de bug et de retrouver toutes ses variantes dans une grosse base de code. C'est une manière rentable de partir d'un bug connu.
Mitigations modernes
ASLR, DEP, canaris de pile, Control Flow Guard et CET sous Windows, PAC et MTE sur ARM. Ces protections ne suppriment pas les bugs mais rendent leur exploitation plus difficile. Évaluer l'exploitabilité d'un bug, c'est d'abord savoir lesquelles s'appliquent sur la cible.
CVE, CVSS et divulgation coordonnée
Une vulnérabilité confirmée est signalée à l'éditeur, qui la corrige avant publication. Un identifiant CVE est attribué par une autorité de numérotation (CNA), la gravité est souvent exprimée en CVSS. Les plateformes de bug bounty comme YesWeHack ou HackerOne encadrent une partie de ces échanges.
Cyber Resilience Act
Depuis le 11 septembre 2026, le règlement (UE) 2024/2847 oblige les fabricants à notifier les vulnérabilités activement exploitées dans leurs produits au CSIRT coordinateur et à l'ENISA, avec une alerte précoce sous 24 heures. Un chercheur qui rejoint un éditeur ou une équipe PSIRT doit connaître ces délais.
Le poste change beaucoup selon l'employeur. Chez un cabinet spécialisé, le chercheur alterne recherche et audits pour des clients. Chez un éditeur, il travaille sur les produits maison avec l'équipe PSIRT, désormais soumise aux obligations de notification du Cyber Resilience Act. Dans un laboratoire lié à la défense, l'habilitation est souvent requise. Les offres demandent du C et du C++, de l'assembleur x86, x64 et ARM, parfois MIPS ou des systèmes temps réel, et une première expérience de reverse ou de recherche. Les profils seniors sont rares et se repèrent par leurs publications, leurs conférences ou leurs résultats en compétition.
Compétences attendues d'un vulnerability researcher
- Choix de cible et surface d'attaque
- Fuzzing et analyse dynamique
- Reverse et diffing de correctifs
- Bugs mémoire et mitigations
- Preuve de concept maîtrisée
- Divulgation coordonnée et cadre légal
Cinq questions de méthode pour un chercheur en vulnérabilités
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
On vous confie un produit à étudier pendant trois mois. Comment choisissez-vous où chercher ?
Une bonne réponseIl cartographie la surface d'attaque : ce qui reçoit des données non fiables (analyseurs de formats, protocoles réseau, interfaces exposées au navigateur ou à un processus moins privilégié), ce qui tourne avec des privilèges élevés, le code ancien ou peu testé. Il regarde l'historique des CVE du produit et les correctifs récents, qui signalent des zones fragiles. Il fixe des points d'étape pour abandonner une piste stérile.
Signal d'alerte« Je lance un fuzzer sur le binaire et j'attends », sans analyse préalable ni critère d'arrêt.
Question 2 · confirmé
Votre campagne de fuzzing tourne depuis une semaine sans nouveau crash. Que regardez-vous ?
Une bonne réponseLa couverture de code atteinte et les zones jamais exécutées, la qualité du corpus de départ, le harnais (bloqué sur une vérification de somme de contrôle, une clé ou un format trop strict), la vitesse d'exécution, la présence des sanitizers. Il ajoute un dictionnaire ou une grammaire du format, contourne les vérifications qui bloquent dans le harnais et change de point d'entrée si la zone est épuisée.
Signal d'alerte« J'ajoute des machines » sans regarder la couverture, ou conclure que le code n'a pas de bug.
Question 3 · confirmé
Le fuzzer a produit 400 crashs en une nuit. Comment les triez-vous ?
Une bonne réponseUne déduplication automatique par pile d'appels et par emplacement du plantage, puis une minimisation des entrées. Le rapport du sanitizer indique la classe de bug (lecture ou écriture hors limites, use-after-free, double libération). Il cherche la cause racine pour chaque groupe et classe par intérêt : une écriture hors limites ou un use-after-free passe avant une lecture nulle. Il sait que plusieurs signatures peuvent venir du même bug.
Signal d'alerteAnalyser les 400 crashs un par un dans le débogueur, ou garder seulement le premier.
Question 4 · senior
Un éditeur publie un correctif de sécurité sans aucun détail. Comment retrouvez-vous ce qu'il corrige, et à quoi cela vous sert-il ?
Une bonne réponseUn diffing entre l'ancienne et la nouvelle version avec BinDiff ou Diaphora, en filtrant les fonctions modifiées pour isoler les nouveaux contrôles. Il explique les usages légitimes : vérifier que le correctif est complet, chercher des variantes du même bug ailleurs dans le code, aider la détection ou évaluer l'urgence pour un client. Il sait que ce travail raccourcit le délai entre correctif et exploitation et le traite avec précaution.
Signal d'alerteAucune méthode, ou un discours qui ne voit aucune question éthique à publier vite une analyse de correctif.
Question 5 · confirmé
Quelles mitigations rencontrez-vous sur une cible récente, et comment changent-elles votre évaluation d'un bug ?
Une bonne réponseIl cite ASLR, DEP, canaris de pile, Control Flow Guard et CET sous Windows, PAC et MTE sur ARM, le cloisonnement par sandbox dans les navigateurs. Il explique ce que chacune protège et en tire l'évaluation : un bug seul ne suffit souvent plus, il faut une fuite d'information, une primitive plus forte ou une seconde vulnérabilité pour sortir de la sandbox. Il dit clairement quand un bug reste un déni de service.
Signal d'alerteUne liste d'acronymes sans savoir ce qu'ils protègent, ou « tout bug mémoire est exploitable ».
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Chercheur en vulnérabilités, questions fréquentes
Chercheur en vulnérabilités ou pentester : quel profil pour quel besoin ?
Le pentester couvre un périmètre client en quelques jours et s'appuie surtout sur des failles connues ou des erreurs de configuration. Le chercheur passe des semaines sur un produit pour y trouver des bugs inédits. Pour auditer des applications et un réseau, un pentester suffit. Pour un produit sensible ou une activité de recherche offensive, il faut un chercheur, et un manager capable de l'évaluer.
Quel test technique pour un chercheur en vulnérabilités ?
Un exercice en direct avec un manager technique : un extrait de code C à lire pour trouver le bug et dire s'il est exploitable selon les protections, ou un crash à trier à partir d'un rapport de sanitizer. Il dure une heure. Les challenges qui prennent un week-end sont à écarter. La façon de raisonner à voix haute dit plus qu'un résultat obtenu seul chez soi.
Une liste de CVE suffit-elle à juger un candidat ?
Non. Le nombre de CVE dépend beaucoup de la cible : un fuzzer lancé sur un logiciel jamais testé peut en produire dix, une seule faille dans un noyau ou un navigateur peut représenter des mois. Pour chaque CVE comptent la cible, la classe de bug, la méthode de découverte et le déroulé de la divulgation. Les publications, conférences et résultats en compétition comme Pwn2Own complètent le tableau.
Quelles règles juridiques un chercheur doit-il connaître en France ?
Les articles 323-1 et suivants du Code pénal, qui punissent l'accès frauduleux à un système et la détention d'outils sans motif légitime, la recherche étant citée comme motif. Tester un service en ligne sans autorisation reste interdit, même pour la bonne cause. L'article L2321-4 du Code de la défense dispense l'ANSSI de transmettre au procureur le signalement d'une personne de bonne foi qui lui révèle une vulnérabilité sans l'avoir rendue publique. Côté éditeur, le Cyber Resilience Act impose des délais de notification.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
