Questions d'entretien auditeur de code source sécurité, du code au rapport

L'auditeur de code source lit le code d'une application pour y trouver des failles qu'aucun scanner ne remonte, puis écrit un rapport qu'un développeur peut appliquer. En entretien, il travaille sur du vrai code, et la façon dont il remonte un flux en dit long.

Recevoir la fiche complète

Mis à jour le Par l'équipe Delectus4 min de lecture

La fiche Auditeur de code source sécurité : technologies, chaîne du poste, une question et la grille d'évaluation

Un auditeur de code source travaille le plus souvent dans un cabinet d'audit ou une équipe d'audit interne, sur des missions courtes : quelques jours pour un composant critique, quelques semaines pour une application entière. Il passe d'un langage à l'autre, Java, C#, PHP, JavaScript, Python ou C, et rend un rapport avec extraits, cotation et correctifs. Les questions d'entretien pour un auditeur de code source doivent donc porter sur du code lu à voix haute, pas sur des définitions.

Le profil se confond facilement avec un pentesteur web qui « fait aussi de l'audit de code », ou avec un ingénieur qui pilote un SAST. Un auditeur aguerri explique pourquoi un contrôle d'autorisation manque, où un nonce est réutilisé, comment une longueur signée contourne une vérification. Il sait écrire une règle Semgrep ou CodeQL pour chercher les variantes d'une faille.

Les postes sont rares et les CV courts sur le sujet. Un extrait de rapport anonymisé, ou une faille racontée de la ligne de code jusqu'à la recommandation, sert de preuve. Le PDF contient 30 questions sur six axes et un cas de 20 minutes sur du code fourni.

Langages, référentiels et outils de l'audit de code

Java, C# et leurs frameworks

Spring, Jakarta EE, ASP.NET Core : la majorité des audits d'applications métier. L'auditeur doit connaître la façon dont chaque framework route les requêtes, applique l'authentification et lie les paramètres aux objets. C'est là que se cachent les failles d'autorisation et d'affectation de masse.

PHP, JavaScript et Python

Laravel, Symfony, Node.js, Django, Flask. Chaque langage a ses pièges : unserialize en PHP, pollution de prototype en JavaScript, templates et pickle en Python. Un bon auditeur cite les pièges propres au langage plutôt qu'une liste générique.

C et C++

Moins fréquents dans les missions, mais présents dès qu'on audite un équipement, un logiciel embarqué ou un composant réseau. Les failles sont mémoire : dépassements de tampon, d'entiers, use-after-free, chaînes de format. Ces compétences ne s'exigent que si le poste les demande vraiment.

Semgrep

Un moteur d'analyse à règles lisibles, rapide et sans compilation. L'auditeur l'utilise pour dégrossir et pour chercher les variantes d'une faille trouvée. Depuis le changement de licence de Semgrep, une partie de la communauté utilise Opengrep, un fork qui reprend le moteur ouvert.

CodeQL

L'outil d'analyse de GitHub, qui transforme le code en base de données et l'interroge avec un langage de requêtes. Il suit des flux complexes entre fichiers et fonctions. Sa licence le réserve à la recherche et au code open source. Sur du code privé, il faut GitHub Code Security, l'une des offres GitHub Advanced Security.

OWASP ASVS et CWE

L'ASVS liste les exigences de vérification d'une application, sa version 5.0 date de mai 2025. Les CWE nomment les faiblesses, et le CWE Top 25 publie chaque année les plus dangereuses (édition 2025 en ligne). Un rapport sérieux rattache chaque faille à une CWE.

Référentiel PASSI

Le référentiel de l'ANSSI pour les prestataires d'audit de la sécurité des systèmes d'information. L'audit de code source y est une activité à part, parmi les cinq de la version 2.2 (2024), avec ses exigences de conduite et de rapport. Pour un poste en cabinet qualifié, la question est de savoir si la personne a déjà été évaluée sur cette activité.

CVSS 4.0

Le système de cotation publié par le FIRST fin 2023. Beaucoup de cabinets l'utilisent ou ont leur propre grille. La façon dont la personne cote une faille dont l'exploitation dépend du contexte en dit long.

L'audit de code se pratique surtout en cabinet, en audit interne de grands groupes et chez des éditeurs de logiciels qui font auditer un produit avant une version majeure. Les missions sont courtes et le changement de langage fréquent, ce qui favorise les profils passés par le développement avant la sécurité. Le métier reste proche du pentest web, dont il est souvent le complément en boîte blanche, et de la recherche de vulnérabilités, qui va plus loin dans l'exploitation. Dans un cabinet qualifié PASSI, l'auditeur doit suivre les exigences du référentiel sur cette activité, y compris la protection du code confié.

Ce qu'un auditeur de code source doit montrer en entretien

  • Méthode et priorisation sur une grosse base de code
  • Failles web et logique d'autorisation
  • Failles mémoire en C et C++
  • Cryptographie mal utilisée
  • Règles Semgrep et CodeQL
  • Rapport, cotation et correctifs

Cinq questions d'entretien, du cadrage au rapport

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.

  1. Question 1 · confirmé

    On vous confie 400 000 lignes de Java et cinq jours d'audit. Par où commencez-vous ?

    Une bonne réponsePar la carte de l'application : points d'entrée (contrôleurs, API, files de messages, tâches planifiées), mécanismes d'authentification et d'autorisation, accès aux données, appels sortants, désérialisation, fichiers de configuration. Il lance un SAST ou Semgrep en parallèle pour dégrossir, puis lit en priorité le code qui touche aux entrées non fiables et aux droits. Il annonce au client ce qui sera couvert en profondeur et ce qui ne le sera pas.

    Signal d'alerteLire les fichiers dans l'ordre alphabétique, ou rendre le rapport brut d'un outil SAST.

  2. Question 2 · confirmé

    Dans une API Spring, l'endpoint GET /factures/{id} vérifie que l'utilisateur est connecté, puis renvoie la facture demandée. Que cherchez-vous ?

    Une bonne réponseUn contrôle d'accès objet par objet (IDOR) : la facture appartient-elle à l'utilisateur ou à son organisation ? Il cherche où ce contrôle devrait vivre (service, requête filtrée par propriétaire, annotation de sécurité) et s'il est appliqué de la même façon sur les autres verbes et routes, export PDF ou endpoint d'administration compris. Il vérifie aussi si l'identifiant est prévisible, sans en faire la protection.

    Signal d'alerteConclure que l'endpoint est sûr parce qu'il exige une authentification.

  3. Question 3 · confirmé

    Dans ce code C, len vient du réseau : char buf[256]; memcpy(buf, pkt->data, len); Que vérifiez-vous, et quelle correction proposez-vous ?

    Une bonne réponseQue len est borné par la taille de buf et par la taille réellement reçue, avant la copie, avec un type non signé cohérent. Sinon c'est un dépassement de tampon sur la pile. Il remonte d'où vient len (champ d'en-tête non vérifié), regarde les protections de compilation présentes et propose une vérification explicite, pas seulement le remplacement de memcpy par une fonction réputée plus sûre.

    Signal d'alerte« Il faut remplacer memcpy par strncpy. »

  4. Question 4 · confirmé

    Vous trouvez Cipher.getInstance("AES") en Java pour chiffrer des données personnelles. Qu'en dites-vous ?

    Une bonne réponseSans mode précisé, le fournisseur Java par défaut utilise en général AES/ECB/PKCS5Padding : ECB chiffre deux blocs identiques de la même façon et laisse voir des motifs. Il recommande un mode authentifié comme AES-GCM, avec un nonce unique par message, et vérifie où et comment la clé est stockée. Il regarde aussi la réutilisation de nonce, fatale en GCM.

    Signal d'alerte« C'est de l'AES, donc c'est sûr. »

  5. Question 5 · senior

    Vous avez confirmé une injection SQL dans un DAO. Comment vérifiez-vous que le même motif n'existe pas dans les autres DAO et les autres dépôts du client ?

    Une bonne réponsePar une analyse de variantes : il décrit le motif (source, transformation absente, sink) dans une règle Semgrep en mode taint ou une requête CodeQL, la lance sur tout le dépôt et sur les autres dépôts du client, puis trie les résultats à la main. Il garde la règle et la remet au client pour sa CI. Un grep simple sert de premier passage, pas de méthode.

    Signal d'alerteSignaler la seule occurrence trouvée en laissant le client chercher les autres.

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

Auditeur de code source : questions fréquentes

Faut-il avoir été développeur pour devenir auditeur de code source ?

Pas obligatoirement, mais c'est le parcours le plus courant et le plus solide. Un auditeur passe ses journées dans du code écrit par d'autres, dans plusieurs langages : il doit lire vite, comprendre un framework qu'il découvre et proposer une correction qui compile. Un pentesteur sans passé de développeur peut y arriver sur le web, plus difficilement sur du C ou sur une architecture complexe. Avoir déjà écrit du code de production compte.

Quelle différence entre un audit de code et un test d'intrusion ?

Le test d'intrusion attaque l'application en fonctionnement, souvent sans voir le code, et prouve l'exploitation. L'audit de code lit les sources et trouve des failles inaccessibles depuis l'extérieur pendant la durée d'un test, comme une logique d'autorisation incomplète ou un chiffrement mal utilisé. Les deux se combinent souvent dans une même mission. Le référentiel PASSI les traite comme deux activités distinctes.

Comment se déroule le test technique d'un auditeur de code source ?

Le test réunit trois ou quatre extraits de code réels et anonymisés, de 50 à 150 lignes, dans les langages du poste, avec une ou deux failles chacun et un piège sans faille. Le candidat a 30 à 45 minutes, puis fait une restitution orale : faille, chemin, impact, correctif. Un extrait de rapport écrit sur l'une des failles montre en plus la qualité de rédaction, aussi importante que la découverte.

Un auditeur doit-il maîtriser tous les langages ?

Non. On attend une vraie profondeur sur deux ou trois langages et la capacité à se mettre vite dans un autre, appuyée par les bases communes : flux de données, sources, sinks, contrôles d'accès. Les langages audités récemment, et sur quel volume, pèsent plus qu'une longue liste. Si le poste inclut du C ou du C++ embarqué, ce point se teste à part, car les failles mémoire demandent une pratique spécifique.

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.

Les fiches voisines

Toutes les fiches →

Voyez Delectus sur vos propres offres.

Commencez gratuitement. Passez à l'échelle quand vous êtes prêt.

Demander une démo

Votre ATS, connecté à Delectus

  • Workable
  • Teamtailor
  • iCIMS
  • Lever
  • SmartRecruiters
  • Jobvite
  • Greenhouse
  • Pinpoint