Les offres d'ingénieur DevSecOps publiées en France citent surtout GitLab CI, Jenkins ou GitHub Actions, SonarQube, Checkmarx ou Fortify pour le code, JFrog Xray ou Nexus IQ pour les dépendances, Vault pour les secrets, Kubernetes et OpenShift pour l'exécution. Les questions d'entretien d'un ingénieur DevSecOps partent de ce qu'il livre : des étapes de pipeline, des règles de blocage, des politiques d'admission et un circuit de traitement des vulnérabilités avec les développeurs.
Deux profils se présentent. Le premier vient du DevOps, connaît bien les pipelines et lit mal un rapport SAST ou une CVE. Le second vient de la sécurité applicative ou du pentest et n'a jamais maintenu une CI. Les deux peuvent réussir, à condition de savoir lequel est en face. Une règle de blocage que la personne a mise en place compte, avec le nombre de faux positifs qu'elle a produits.
La réglementation pousse aussi le poste. Le Cyber Resilience Act européen impose aux fabricants de produits logiciels le signalement des vulnérabilités exploitées à partir de septembre 2026, et ses autres obligations en décembre 2027, dont l'inventaire des composants. Les SBOM deviennent un sujet d'audit.
La chaîne d'outils d'un ingénieur DevSecOps
SAST (SonarQube, Checkmarx, Fortify, Semgrep)
L'analyse statique lit le code source sans l'exécuter et signale des failles connues : injection SQL, désérialisation dangereuse, chiffrement faible. Sans réglage, elle produit beaucoup de faux positifs. L'ingénieur choisit ce qui bloque un merge et ce qui reste un avertissement.
SCA et SBOM (Dependency-Track, Snyk, JFrog Xray, Syft)
L'analyse de composition repère les bibliothèques open source vulnérables ou sous une licence gênante. Le SBOM en est l'inventaire, au format CycloneDX ou SPDX, produit à chaque build. Dependency-Track le conserve et prévient quand une nouvelle CVE touche un composant déjà en production.
Scan d'images (Trivy, Grype, Harbor)
Une image de conteneur embarque un système et des paquets qui vieillissent. Trivy ou Grype la scannent dans la CI, Harbor ou Artifactory la rescannent dans le registre. Une image de base minimale (distroless, Alpine, images durcies) réduit le nombre d'alertes à traiter.
Détection de secrets (Gitleaks, GitGuardian, GitLab, GitHub)
Repère les mots de passe, jetons et clés d'API poussés dans le code. Un hook avant commit empêche la fuite, le scan de l'historique retrouve les anciennes. Un secret trouvé se révoque : le supprimer du dépôt ne suffit pas.
Coffres à secrets (HashiCorp Vault, OpenBao)
Les applications et les pipelines y lisent leurs identifiants au lieu de les garder en variables. Les configurations les plus sûres donnent des secrets de courte durée créés à la demande, et la CI s'y authentifie par un jeton OIDC plutôt que par un mot de passe.
Signature et provenance (Sigstore cosign, SLSA)
cosign signe les images et y attache des attestations, comme la provenance qui dit quel pipeline a construit quoi, à partir de quel commit. SLSA, publié en version 1.2, définit des niveaux de garantie sur la construction. La signature n'a d'intérêt que si le déploiement la vérifie.
Policy as code (Kyverno, OPA, Checkov)
Des règles écrites et versionnées comme du code. Checkov et Trivy contrôlent les fichiers Terraform et les manifests Kubernetes avant le déploiement (tfsec fait désormais partie de Trivy). Kyverno ou OPA Gatekeeper refusent à l'entrée du cluster un pod qui tourne en root ou une image non signée.
DAST (ZAP, Burp Suite)
L'analyse dynamique attaque l'application en fonctionnement, sur un environnement de recette. Elle trouve ce que le SAST ne voit pas : en-têtes manquants, failles d'authentification, configuration du serveur. Elle est lente, d'où un scan court dans la CI et un scan complet planifié.
Le poste porte plusieurs noms : ingénieur DevSecOps, consultant DevSecOps, ingénieur sécurité des pipelines. Il dépend de l'équipe plateforme ou de l'équipe sécurité, et ce rattachement change le quotidien. Côté plateforme, il construit les modèles de pipeline que tous les projets réutilisent. Côté sécurité, il fixe les règles, suit les vulnérabilités et accompagne les développeurs. Les offres françaises demandent souvent une migration de chaîne CI/CD, vers GitLab par exemple, avec la sécurité intégrée dès le départ. Les certifications citées varient : CKS pour Kubernetes, certifications d'éditeurs, certifications de sécurité généralistes. Aucune ne remplace un pipeline réellement déployé sur des dizaines de projets.
Les savoir-faire techniques attendus d'un ingénieur DevSecOps
- Sécurité de la chaîne CI/CD
- SAST, SCA et réglage des faux positifs
- Images, registres et SBOM
- Gestion et rotation des secrets
- Signature, provenance et contrôle au déploiement
- Triage et priorisation des vulnérabilités
Pipeline, images et secrets : les questions d'un entretien DevSecOps
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é
Gitleaks signale une clé d'accès cloud poussée sur la branche principale il y a trois semaines. Que faites-vous, et dans quel ordre ?
Une bonne réponseD'abord révoquer la clé et en émettre une nouvelle, avant tout nettoyage du dépôt. Ensuite chercher dans les journaux du fournisseur (CloudTrail, journal d'activité Azure, Cloud Audit Logs) ce qui a été fait avec cette clé depuis sa publication. Puis retirer le secret de l'historique si la politique l'exige, en sachant que les clones et les forks existants le gardent. Enfin, un hook avant commit et la protection au push pour éviter la récidive, et si possible une authentification sans clé longue durée pour ce besoin.
Signal d'alerte« Je supprime le fichier et je fais un nouveau commit » : la clé reste dans l'historique et reste valide.
Question 2 · confirmé
Vous activez le SAST sur un projet existant et il remonte 1 200 alertes. Que faites-vous ?
Une bonne réponseNe pas bloquer sur l'existant. On fixe une base de référence et on ne bloque que les nouvelles alertes introduites par une merge request. L'existant est trié par gravité et par exposition (code atteignable depuis une entrée utilisateur), les règles bruyantes qui ne correspondent pas à la stack sont désactivées, et les faux positifs sont marqués avec une justification. Les développeurs voient les alertes dans la merge request, pas dans un rapport à part.
Signal d'alerteBloquer tous les merges jusqu'à zéro alerte, ou désactiver l'outil parce qu'il fait trop de bruit.
Question 3 · confirmé
Trivy trouve 85 vulnérabilités dans une image de production. Lesquelles traitez-vous en premier ?
Une bonne réponseUn tri : celles qui ont un correctif disponible, les gravités élevées, celles qui ont un exploit connu, celles qui touchent des paquets réellement utilisés à l'exécution. Une bonne part vient souvent de l'image de base, et passer à une image minimale ou à jour en supprime beaucoup d'un coup. Les vulnérabilités sans correctif ou non exploitables dans ce contexte sont documentées, dans un fichier d'exceptions avec une date de revue ou une déclaration VEX.
Signal d'alerteTout corriger dans l'ordre de la liste, ou ignorer le rapport parce qu'il est trop long.
Question 4 · senior
Comment garantissez-vous qu'une image qui tourne en production a bien été construite par votre pipeline, à partir du code relu ?
Une bonne réponseLe pipeline signe l'image par son digest avec cosign, en mode sans clé (identité OIDC du job, journal de transparence Rekor) ou avec une clé gardée dans un KMS. Il attache une attestation de provenance au format SLSA qui relie l'image au commit et au pipeline. À l'entrée du cluster, une politique Kyverno ou le policy-controller de Sigstore vérifie la signature et l'identité du signataire, et refuse le reste. Le déploiement se fait par digest, jamais par un tag modifiable.
Signal d'alerte« On scanne l'image », ce qui ne prouve rien sur son origine, ou une signature que personne ne vérifie au déploiement.
Question 5 · confirmé
Où sont rangés les secrets de vos applications, et comment les faites-vous tourner ?
Une bonne réponseDans un coffre (Vault, OpenBao ou le gestionnaire de secrets du cloud), jamais dans le dépôt ni dans l'image. Les applications les lisent au démarrage, par un agent, ou via External Secrets Operator qui les synchronise dans Kubernetes. La rotation est automatique pour les identifiants de base de données (secrets dynamiques à durée courte) et planifiée pour le reste, avec un essai qui prouve que l'application encaisse le changement sans redémarrage manuel.
Signal d'alerteDes fichiers .env sur les serveurs, ou des Secrets Kubernetes écrits en clair dans le dépôt Git.
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
Ingénieur DevSecOps, les réponses aux questions courantes
Quelle différence entre un ingénieur DevSecOps et un ingénieur sécurité cloud ?
L'ingénieur DevSecOps travaille sur la chaîne de livraison : code, dépendances, images, pipeline, déploiement. L'ingénieur sécurité cloud s'occupe de la configuration des comptes et des abonnements, des identités, du réseau et de la détection des menaces sur l'infrastructure. Les deux se croisent sur l'infrastructure as code et sur Kubernetes. Pour des pipelines GitLab ou Jenkins à sécuriser, le premier profil convient. Pour une organisation AWS ou Azure à durcir, le second.
Un développeur peut-il devenir ingénieur DevSecOps ?
Oui, surtout s'il a déjà maintenu des pipelines et lit facilement le code des autres. Il reconnaît un faux positif de SAST et sait parler aux équipes de leur code. Ce qui lui manque en général : l'exploitation des runners et des registres, la gestion des secrets à l'échelle d'une organisation, Kubernetes et les politiques d'admission. L'entretien insiste sur ces points plutôt que sur l'OWASP Top 10, dont l'édition 2025 lui est souvent familière.
Comment vérifier en pratique le niveau d'un ingénieur DevSecOps ?
L'exercice part d'un petit dépôt avec un fichier de pipeline, un Dockerfile et un fichier de dépendances qui contiennent quelques défauts volontaires : une image en latest qui tourne en root, une clé d'API dans l'historique, une bibliothèque vulnérable, un job qui affiche ses variables. En trente minutes, il dit ce qu'il corrige en premier et pourquoi. Ce test technique montre sa façon de hiérarchiser, ce qu'une liste d'outils récitée ne montre pas.
Quelles certifications regarder sur un CV DevSecOps ?
Aucune certification ne fait référence à elle seule. La CKS (Certified Kubernetes Security Specialist) montre une pratique de la sécurité Kubernetes, et les certifications d'éditeurs, chez GitLab ou HashiCorp pour Vault, attestent la connaissance d'un outil. Les certifications de sécurité généralistes apportent la culture du risque. Aucune ne dit si la personne a déjà déployé des contrôles sur des dizaines de projets. Un exemple précis, avec les chiffres de faux positifs, le montre.
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.
