Un ingénieur SAST / SCA tient la plateforme plus qu'il ne cherche des failles lui-même. Il administre Checkmarx, OpenText Fortify ou Veracode pour l'analyse du code, Sonatype, Snyk, Mend ou JFrog Xray pour les dépendances, et les branche dans GitLab CI, Jenkins ou Azure DevOps. Sur Free-Work, Checkmarx et SonarQube reviennent dans des offres DevSecOps comme dans des postes de développeur, et Fortify dans des missions de support de plateforme.
Le CV dit rarement ce que la personne a réellement fait de l'outil. Avoir lancé des scans et lu des rapports n'a rien à voir avec écrire une query, mettre à jour des rulepacks sur 150 applications ou migrer l'historique de triage d'une plateforme à l'autre. Trois faits comptent : le nombre d'applications administrées, une règle corrigée, une quality gate écrite.
La manière dont la personne parle des faux positifs en dit long. Un profil solide les traite à la source, par une règle ou un sanitizer déclaré une fois pour tout le parc, et sait expliquer pourquoi deux outils ne trouvent pas la même chose. Le PDF déroule l'entretien en 30 questions sur six axes, avec un cas de 20 minutes.
Plateformes et intégrations d'un ingénieur outillage AppSec
Checkmarx One (et CxSAST)
La plateforme de Checkmarx réunit SAST, SCA et d'autres analyses, en SaaS. CxSAST est l'ancienne version installée, encore présente chez beaucoup de clients. Les queries s'écrivent en CxQL et se surchargent dans le Query Editor. Reste à savoir si la personne a déjà écrit ou modifié une query, ou seulement choisi un preset.
OpenText Fortify
Fortify Static Code Analyzer analyse le code, Software Security Center centralise résultats et audits, ScanCentral SAST répartit les scans. OpenText renomme ces produits depuis 2025 (OpenText SAST, OpenText Application Security), mais les CV et les offres disent encore Fortify. Sur un poste d'administration, la mise à jour des rulepacks et le diagnostic d'un scan raté comptent beaucoup.
Veracode
Une plateforme SaaS qui analyse un paquet compilé préparé par l'équipe, avec des scans de politique, des sandboxes et un Pipeline Scan pour la CI. Les développeurs proposent des mitigations que l'équipe sécurité valide. Préparer le paquet d'une application Java ou .NET fait partie du poste.
Sonatype, Snyk, Mend, Black Duck
Les outils de SCA identifient les composants open source, leurs vulnérabilités et leurs licences. Sonatype Lifecycle (le produit appelé autrefois Nexus IQ) fonctionne par politiques et dérogations. Snyk et Mend sont très présents dans les intégrations CI, Black Duck sait identifier du code sans manifeste. JFrog Xray revient souvent dans les offres françaises.
SonarQube
D'abord un outil de qualité de code, avec des règles de sécurité et des quality gates sur le nouveau code. Sonar distingue depuis fin 2024 SonarQube Server, SonarQube Cloud et la Community Build. Il cohabite souvent avec Checkmarx ou Fortify, et la personne doit savoir qui fait quoi.
GitLab CI, Jenkins, Azure DevOps
Les chaînes dans lesquelles les scans s'exécutent. L'ingénieur fournit des modèles de pipeline communs plutôt que des copies par projet, gère les jetons de la plateforme et décide de ce qui bloque une merge request. Une bonne réponse sur ce sujet parle de maintenance de 200 dépôts.
Semgrep et CodeQL
Deux moteurs à règles ouvertes, utilisés en complément ou à la place d'un SAST commercial. Leurs règles se lisent et s'écrivent rapidement, ce qui en fait un bon support d'exercice en entretien. CodeQL est inclus sur les dépôts publics de GitHub. Sur du code privé, il faut GitHub Code Security, l'une des offres GitHub Advanced Security.
SARIF, DefectDojo et ASPM
SARIF est le format d'échange standard des résultats d'analyse statique. DefectDojo, open source, et les outils d'ASPM consolident SAST, SCA, secrets et IaC par application et dédoublonnent. La personne doit savoir que le dédoublonnage entre outils reste imparfait.
Le poste porte plusieurs noms : expert Checkmarx, administrateur Fortify, ingénieur AppSec outillage, parfois consultant DevSecOps quand la mission couvre aussi la chaîne CI. Chez un client final, il administre une ou deux plateformes pour tout le parc et fixe les règles du jeu avec le RSSI. En mission, il arrive souvent pour une installation, une migration de CxSAST vers Checkmarx One ou un changement d'éditeur. Le rôle se distingue de l'ingénieur sécurité applicatif généraliste, qui fait aussi de la modélisation de menaces et de la revue de code, et de l'auditeur de code, qui lit le code à la main. Le Cyber Resilience Act européen pousse les éditeurs de logiciels à mieux connaître leurs composants, ce qui donne du poids à la partie SCA.
Les savoir-faire à valider chez un ingénieur SAST / SCA
- Paramétrage et couverture des moteurs SAST
- Administration des plateformes et des droits
- Politiques SCA et licences
- Intégration CI et quality gates
- Réglage des règles et triage à l'échelle
- API, indicateurs et migrations
Cinq questions techniques pour un ingénieur outillage SAST / SCA
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é
Fortify ne remonte presque rien sur une application Java de 300 000 lignes. Que vérifiez-vous avant de conclure que le code est propre ?
Une bonne réponseLa phase de traduction d'abord. Fortify analyse ce que sourceanalyzer a réussi à traduire : classpath incomplet, dépendances introuvables, version de Java non prise en charge ou fichiers ignorés donnent un scan presque vide. Il lit les avertissements de traduction, compare le nombre de fichiers et de lignes analysés à la taille réelle du projet, puis vérifie que les rulepacks sont à jour et que le framework web est reconnu, sinon les entrées utilisateur ne sont pas vues comme des sources.
Signal d'alerte« Zéro résultat, c'est une bonne nouvelle. » Ou relancer le scan avec plus de mémoire sans ouvrir le journal.
Question 2 · senior
Vous administrez Fortify pour 150 applications. Une mise à jour des rulepacks fait apparaître 2 000 nouvelles alertes du jour au lendemain. Que faites-vous ?
Une bonne réponseIdéalement, cela n'arrive pas en production : les rulepacks se testent d'abord sur quelques applications de référence, avec les notes de version. Une fois le cas présent, il compare les résultats avant et après, sépare les nouvelles catégories des alertes simplement reclassées, suspend temporairement le blocage des quality gates sur ces nouveautés et prévient les équipes avec la liste triée. Il vérifie aussi que l'historique d'audit est bien reporté sur les résultats existants.
Signal d'alerteAnnuler la mise à jour et rester sur d'anciennes règles, ou laisser toutes les pipelines casser le lendemain matin.
Question 3 · confirmé
Snyk et Sonatype ne remontent pas les mêmes vulnérabilités sur la même application. Comment l'expliquez-vous ?
Une bonne réponseLes bases de vulnérabilités diffèrent (NVD, GitHub Advisory, OSV, recherche propre à l'éditeur) et n'ont pas la même date de mise à jour. L'identification des composants aussi : lecture du manifeste, du lockfile ou empreinte des binaires, dépendances transitives résolues ou non, dépendances de test incluses ou exclues. Il prend un écart précis, remonte au composant et à sa version réelle, et tranche avec l'avis de sécurité d'origine.
Signal d'alerte« L'un des deux outils se trompe. » Ou choisir celui qui remonte le moins d'alertes.
Question 4 · confirmé
Vous branchez Checkmarx One sur GitLab CI pour 200 dépôts. Comment éviter d'écrire 200 fichiers de pipeline ?
Une bonne réponseUn modèle central versionné, inclus par chaque projet (include ou composant CI/CD GitLab), avec les paramètres par variables de groupe. Ou l'intégration native par import du gestionnaire de code et webhooks, qui scanne sans toucher au fichier de pipeline. Le jeton de la plateforme est un compte de service à droits limités, stocké en variable masquée et protégée. Une montée de version du modèle passe d'abord sur quelques projets pilotes.
Signal d'alerteCopier le même bloc YAML dans chaque dépôt, avec un jeton administrateur en clair.
Question 5 · confirmé
Un développeur a marqué une alerte en faux positif. Après un refactoring, elle revient au scan suivant. Pourquoi, et que faites-vous ?
Une bonne réponseL'outil reconnaît un résultat déjà trié par un identifiant calculé sur le chemin, le fichier, la méthode ou le flux (similarity ID chez Checkmarx, instance ID chez Fortify). Un fichier renommé ou une méthode déplacée change cet identifiant, et le résultat revient comme nouveau. Il explique ce mécanisme aux équipes et reprend le triage. Si un faux positif revient sans cesse, mieux vaut corriger la règle qu'empiler les statuts.
Signal d'alerte« L'outil est bogué. » Ou demander au développeur de ne plus refactorer.
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 SAST / SCA : les questions fréquentes
Quelle différence entre un ingénieur outillage SAST / SCA et un ingénieur sécurité applicative ?
L'ingénieur sécurité applicative couvre un champ large : modélisation des menaces, exigences de sécurité, revue de code, accompagnement des équipes. L'ingénieur outillage se concentre sur les plateformes d'analyse et leur fonctionnement à grande échelle : installation, règles, intégration CI, droits, migrations, indicateurs. Dans une petite équipe, une même personne fait les deux. Au-delà d'une centaine d'applications, l'outillage devient souvent un poste à part entière, proche de l'ingénierie de plateforme.
Un spécialiste Fortify peut-il prendre en main Checkmarx ou Veracode ?
Oui, les notions se transposent : flux de données, sources et sinks, presets ou filtres, quality gates, triage. Ce qui change, c'est la façon d'écrire une règle personnalisée, la préparation du code (build intercepté, paquet compilé ou sources seules) et le modèle d'administration. Il faut quelques semaines pour être autonome. Le point décisif : avoir administré la plateforme, et pas seulement consulté ses rapports.
Quel test technique est donné à un ingénieur SAST / SCA ?
Un exercice d'une demi-heure suffit. Le support est une exportation de résultats SAST d'une petite application avec dix alertes, dont plusieurs faux positifs, et un extrait de configuration de pipeline. La personne trie les alertes, propose une correction de règle pour le faux positif récurrent et une quality gate pour la merge request. L'exercice montre la lecture d'un flux de données, le raisonnement de réglage et le sens pratique de la CI.
Quels signaux sur un CV d'expert Checkmarx ou Fortify méritent une question ?
Le nombre d'applications ou de dépôts administrés, une migration menée, des règles écrites ou surchargées, une intégration CI fournie à plusieurs équipes. Les formations des éditeurs montrent une connaissance du produit, sans dire comment la plateforme était exploitée. Une liste de six outils sans un seul exemple de réglage doit alerter : c'est souvent le profil de quelqu'un qui a lu les rapports produits par d'autres.
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.
