Questions d'entretien AppSec et DevSecOps : la grille
Les questions d'entretien à poser à un ingénieur AppSec ou DevSecOps, classées par thème, avec les bonnes réponses attendues et les signaux d'alerte.
Un entretien pour un poste de sécurité applicative glisse facilement vers une récitation du OWASP Top 10 ou une liste d'outils d'analyse. On en ressort sans savoir si le candidat saura relire votre code, régler une chaîne CI/CD ou convaincre une équipe de développement de corriger. Voici une grille de questions organisée par thème, avec ce qu'une bonne réponse contient et les signaux qui doivent vous alerter.
Avant l'entretien : savoir quel profil vous évaluez
« AppSec » et « DevSecOps » recouvrent des postes différents. Avant de préparer vos questions, précisez la dominante du poste :
- Outillage et chaîne de livraison : intégration de l'analyse statique, de l'analyse des dépendances, de la détection de secrets et de l'analyse des conteneurs dans la CI/CD.
- Revue et conception : modélisation des menaces, relecture du code sensible, conseils d'architecture.
- Programme : référents sécurité, formation des développeurs, pilotage des corrections, relation avec les pentesters et le bug bounty.
Notez aussi les langages et frameworks utilisés chez vous, et le nombre de développeurs que la personne accompagnera. Si ces points ne sont pas encore tranchés, commencez par notre guide pour recruter un ingénieur sécurité applicative. Une grille construite sur un besoin flou compare les candidats sur des critères qui ne comptent pas.
Faites participer un développeur de l'équipe à au moins une partie de l'entretien. Il saura juger si le candidat parle le langage des équipes, ce qu'aucune question technique ne mesure seule.
Vulnérabilités et lecture de code
« Prenez une vulnérabilité que vous connaissez bien. Montrez-moi à quoi elle ressemble dans le code, puis comment la corriger. »
Une bonne réponse part d'un exemple concret dans un langage que le candidat maîtrise : une requête construite par concaténation, un contrôle d'accès vérifié seulement côté client, un identifiant d'objet qui n'est jamais rapproché de l'utilisateur connecté. La correction est précise (requête paramétrée, vérification côté serveur, contrôle objet par objet) et le candidat explique pourquoi elle fonctionne.
Signal d'alerte : une définition de manuel sans aucun exemple de code.
« Comment suivez-vous une donnée utilisateur, de l'entrée jusqu'à une fonction sensible ? »
On attend une méthode : identifier les points d'entrée (paramètres, en-têtes, fichiers, messages), suivre les transformations, repérer où la donnée est validée, encodée ou utilisée telle quelle. Les meilleurs candidats parlent aussi des chemins indirects, comme une donnée stockée puis relue plus tard par un autre service.
« Quelle est la différence entre authentification et autorisation, et où voyez-vous le plus d'erreurs ? »
La définition est simple ; la seconde partie est révélatrice. Un praticien cite souvent l'autorisation objet par objet dans les API, les fonctions d'administration exposées sans contrôle ou les jetons dont la validité n'est pas vérifiée correctement.
Sécurité des API et de l'architecture
« On vous présente une nouvelle API publique. Quelles questions posez-vous à l'équipe avant la mise en production ? »
Attendus : qui peut appeler quoi, comment l'identité est transmise et vérifiée, quelles données sont renvoyées (et si elles sont toutes nécessaires), quelle limitation de débit, quelle journalisation, quelles anciennes versions restent accessibles. Le candidat doit poser des questions avant de donner des réponses.
« Comment animeriez-vous un atelier de modélisation des menaces avec une équipe qui n'en a jamais fait ? »
On cherche quelqu'un de pragmatique : un schéma simple de l'application, les frontières de confiance, quelques scénarios réalistes, une liste d'actions courte et attribuée. Signal d'alerte : un atelier de plusieurs jours avec un formalisme lourd, présenté comme un prérequis à tout projet.
« Comment repérez-vous une mauvaise utilisation de la cryptographie dans une application ? »
Pas besoin de mathématiques. On attend des exemples concrets : stockage de mots de passe sans fonction de hachage adaptée, algorithme dépassé, clé ou secret codé en dur, génération d'aléa inadaptée, chiffrement maison.
Chaîne de livraison et DevSecOps
Cette partie pèse davantage si le poste est orienté outillage.
« Vous devez intégrer l'analyse statique dans la CI/CD de vingt équipes. Comment vous y prenez-vous ? »
Une bonne réponse commence petit : un ou deux projets pilotes, des règles limitées à ce qui a un vrai impact, un réglage des faux positifs avant le déploiement large. Le candidat distingue ce qui bloque une fusion de ce qui crée seulement un ticket, et parle de la façon dont les résultats arrivent aux développeurs (dans la demande de fusion plutôt que dans un tableau de bord que personne ne consulte).
Signal d'alerte : « J'active toutes les règles et je bloque tout ce qui ressort. »
« Un secret a été poussé dans un dépôt Git. Que faites-vous, dans l'ordre ? »
Attendus : considérer le secret comme compromis, le révoquer et le renouveler en priorité, vérifier son utilisation dans les journaux, puis seulement nettoyer l'historique si nécessaire. Le candidat ajoute une détection préventive pour éviter que cela se reproduise. Supprimer le commit sans révoquer le secret est une erreur classique.
« Comment gérez-vous le risque lié aux dépendances tierces ? »
On attend l'inventaire des dépendances, l'analyse des vulnérabilités connues avec une priorisation selon l'exploitabilité réelle, la mise à jour régulière, la vérification de la provenance des paquets et la protection de la chaîne de construction elle-même (droits des pipelines, secrets des runners, signature des artefacts).
« Qu'est-ce qui doit vraiment bloquer une mise en production ? »
C'est une question de jugement. Un bon candidat propose des critères clairs, connus à l'avance, et un circuit d'exception documenté. Il sait qu'un contrôle qui bloque trop souvent finit contourné.
Collaboration avec les développeurs
C'est souvent ce qui sépare un bon ingénieur AppSec d'un excellent.
« Une équipe doit livrer demain et vous trouvez une faille de contrôle d'accès. Que faites-vous ? »
On cherche une réponse graduée : évaluer l'exploitabilité réelle, en parler directement avec l'équipe, proposer une correction ou une mesure temporaire, et faire remonter la décision au bon niveau si le risque est accepté. Ni blocage automatique, ni silence.
« Racontez-moi une fois où un développeur n'était pas d'accord avec votre constat. »
Écoutez la précision du récit et le ton. Le candidat doit avoir écouté l'argument (le développeur avait parfois raison sur le contexte), apporté une preuve et trouvé une issue. Relancez sur les détails ; un récit vécu résiste aux relances.
« Qu'avez-vous construit qui a fait disparaître durablement un type de vulnérabilité ? »
Les meilleurs profils citent une bibliothèque sûre, un modèle de projet, une configuration par défaut ou une règle de détection maison. Ils mesurent leur réussite aux vulnérabilités évitées, pas au nombre de tickets ouverts.
Grille de synthèse
Notez tous les candidats sur la même grille, juste après l'entretien.
| Thème | Ce que vous cherchez | Signal d'alerte |
|---|---|---|
| Vulnérabilités | Exemples en code, corrections précises | Définitions récitées sans code |
| Lecture de code | Méthode de suivi des données, logique métier | Confiance totale dans les outils |
| API et architecture | Questions avant réponses, modélisation pragmatique | Formalisme lourd, aucune priorisation |
| Chaîne de livraison | Déploiement progressif, réglage des faux positifs | Tout activer, tout bloquer |
| Gestion des incidents de code | Révocation d'abord, prévention ensuite | Nettoyage de l'historique sans révocation |
| Collaboration | Échange factuel, solutions applicables | Ton condescendant envers les développeurs |
Conseils si vous n'êtes pas spécialiste
Vous pouvez mener une partie utile de l'entretien sans être expert en sécurité applicative.
- Demandez des exemples vécus : « La dernière fois, qu'avez-vous fait exactement ? »
- Relancez par « pourquoi » : un praticien justifie ses choix, un candidat qui récite s'arrête vite.
- Demandez une explication pour un public non technique : un ingénieur AppSec devra convaincre des chefs de produit et une direction.
- Observez l'attitude envers les développeurs : respect, curiosité pour leurs contraintes, envie de les outiller.
- Ne décidez pas sur les certifications seules : notre article sur les certifications en cybersécurité explique ce qu'elles prouvent et ce qu'elles ne prouvent pas.
Compléter l'entretien par un exercice pratique
L'entretien mesure le raisonnement et la communication. Il mesure mal la capacité à trouver une faille dans du code inconnu ou à durcir un pipeline réel. Un exercice court comble ce manque : un extrait de code volontairement vulnérable à relire, une petite application de test, ou une configuration de pipeline à corriger. Jamais votre code de production sans accord préalable.
La discussion qui suit, idéalement avec un développeur présent, est souvent plus riche que l'entretien lui-même : « pourquoi ce constat d'abord ? Comment le feriez-vous corriger ? » Notre guide pour évaluer les compétences en cybersécurité explique comment concevoir un exercice équitable, et notre grille de questions d'entretien pour un pentester vous aidera si votre besoin penche davantage vers le test que vers la prévention.
En résumé
Une bonne grille d'entretien AppSec et DevSecOps couvre les vulnérabilités vues dans le code, la lecture de code, la sécurité des API et de l'architecture, la chaîne de livraison et, surtout, la collaboration avec les développeurs. Adaptez le poids de chaque thème à la dominante du poste, privilégiez les exemples vécus, notez tout le monde de la même façon et complétez par un exercice pratique.
Vous recrutez un ingénieur AppSec ou DevSecOps ? Chez Cyber Recrut, un recruteur et un praticien de la sécurité mènent chaque recherche ensemble, et nos candidats présélectionnés prouvent leurs compétences sur des labs pratiques proches de vos technologies. Découvrez notre méthode ou confiez-nous votre recrutement.