Développeur de solutions de sécurité : concevoir les outils qui protègent les systèmes

Qu’est-ce qu’un développeur de solutions de sécurité ?

Ce métier est régulièrement confondu avec celui de spécialiste en développement sécurisé. La distinction est pourtant nette, et elle change tout au quotidien.

L’AppSec Engineer rend sûres les applications que son organisation produit. Le développeur de solutions de sécurité fabrique les produits de sécurité que d’autres organisations déploieront.

Le Panorama des métiers de la cybersécurité de l’ANSSI décrit ce profil sous l’intitulé « Développeur de solutions de sécurité », dans la famille « Conseil, services et recherche », avec pour équivalent anglais Security product developer. Il précise qu’il intervient au sein de sociétés de conception de solutions et de produits de sécurité adaptés au contexte des menaces de cybersécurité.

Quels produits développe-t-il ?

• Un agent EDR installé sur des dizaines de milliers de machines
• Un moteur de détection ou de corrélation
• Un scanner de vulnérabilités
• Une solution de gestion des identités et des accès
• Un composant de chiffrement ou un élément de PKI
• Un proxy, un pare-feu applicatif ou une passerelle de filtrage
• Un outil d’investigation numérique
• Un analyseur de fichiers ou de trafic
• Un produit de sécurité pour environnements cloud
• Une plateforme de gestion des vulnérabilités

Les appellations rencontrées

• Développeur de solutions de sécurité
• Security Software Developer
• Security Developer
• Cybersecurity Software Engineer
• Security Product Developer
• Ingénieur développement sécurité

Ce qui distingue le développement d’un produit de sécurité

Les compétences de base sont celles de tout bon développeur. Ce sont les contraintes qui changent, et elles sont sévères.

1. Le produit est une cible

   Un produit de sécurité intéresse particulièrement les attaquants : le compromettre donne accès à tout ce qu’il protège. Les exigences de robustesse du code sont donc plus élevées que pour une application ordinaire.

2. Il traite des données hostiles

   Un moteur d’analyse reçoit par définition des fichiers et des flux potentiellement malveillants. Le parsing est historiquement l’une des principales sources de vulnérabilités dans ces produits.

3. Il s’exécute souvent en privilège élevé

   Un agent de sécurité tourne fréquemment avec des droits importants, parfois dans le noyau. Une erreur de gestion mémoire n’y a pas les mêmes conséquences qu’ailleurs.

4. Il ne doit pas gêner

   Un produit qui consomme trop de ressources ou provoque des dysfonctionnements sera désactivé par les équipes d’exploitation. La performance n’est pas un confort, c’est une condition d’adoption.

5. Il doit être fiable à grande échelle

   Un défaut qui se manifeste sur une machine sur mille devient un incident majeur sur un parc de cent mille postes.

6. Il vieillit mal s’il n’est pas maintenu

   Les menaces évoluent. Un moteur de détection non maintenu perd sa valeur en quelques mois, ce qui impose un rythme de maintenance évolutive soutenu.

La formule qui résume le métier : une vulnérabilité dans un produit de sécurité n’est pas un bug, c’est une porte d’entrée supplémentaire chez tous les clients à la fois.

Ses missions

La fiche ANSSI structure l’activité en quatre temps : analyse, développement, qualification et maintenance. Voici ce que cela recouvre.

1. Analyser les besoins et le contexte des menaces

   Comprendre ce que le produit doit protéger ou détecter, face à quelles techniques d’attaque réellement observées. Une fonctionnalité qui ne correspond à aucune menace réelle encombre le produit.

2. Contribuer aux spécifications

   Participer à la définition des spécifications générales de la solution, avec les équipes produit et parfois la recherche interne.

3. Réaliser l’analyse technique

   Étude détaillée de la solution : architecture logicielle, choix technologiques, contraintes de performance, compatibilité avec les environnements cibles.

4. Développer

   Écrire le code, en appliquant les pratiques de développement sécurisé. L’ANSSI mentionne également la planification et la conduite des projets de développement.

5. Qualifier

   Réaliser les tests vérifiant que les solutions répondent bien aux exigences de protection ou de détection attendues, y compris face à des entrées malformées ou hostiles.

6. Intégrer

   Contribuer à l’implémentation du produit dans une architecture logicielle et le tester dans cet ensemble.

7. Assurer la maintenance

   Maintenance corrective et évolutive : correction des défauts, adaptation aux nouvelles menaces, support aux versions déployées chez les clients.

8. Gérer les vulnérabilités du produit

   Traiter les signalements internes ou externes, produire les correctifs et coordonner leur diffusion. Une activité peu visible mais critique.

9. Suivre les dépendances

   Les bibliothèques tierces utilisées par le produit sont une surface d’attaque à part entière, et un sujet devenu majeur.

10. Appuyer la recherche interne

    Dans beaucoup d’éditeurs, chercheurs et pentesters internes travaillent étroitement avec les développeurs pour transformer une découverte en capacité produit.

Langages et technologies

Une précision d’emblée : ce qui suit est une liste d’exemples, pas un prérequis. Personne ne maîtrise l’ensemble, et le choix dépend entièrement du produit développé.

Le choix du langage suit le produit

Un agent devant s’exécuter au plus près du système, avec une empreinte minimale, appellera naturellement C, C++ ou de plus en plus Rust — dont les garanties mémoire présentent un intérêt évident pour un produit de sécurité. Un moteur de corrélation ou un service back-end s’écrira volontiers en Go, Java ou C#. L’outillage, les prototypes et l’analyse se font fréquemment en Python.

Règle constante quel que soit le produit : on n’implémente jamais soi-même une primitive cryptographique. On utilise une bibliothèque éprouvée, correctement.

Développeur sécurité, AppSec, développeur classique, DevSecOps, chercheur

1. Développeur de solutions de sécurité

   Construit un produit dont la finalité est la sécurité. Son client est externe, son livrable est un logiciel à maintenir sur plusieurs années.

2. Spécialiste en développement sécurisé (AppSec)

   Aide les équipes de son organisation à produire du code sûr. Ne développe généralement pas le produit lui-même : il outille, accompagne et forme.

3. Développeur classique

   Mêmes compétences de base, contraintes de robustesse et de menace nettement moins fortes.

4. DevSecOps

   Travaille sur la chaîne de livraison et l’infrastructure. Sécurise la façon dont on livre, pas ce que l’on livre.

5. Chercheur en sécurité

   Découvre et caractérise. Dans un éditeur, il alimente le développement en connaissances nouvelles sans porter la responsabilité du produit.

Dans un éditeur de solutions de sécurité, ces cinq rôles coexistent souvent dans le même bâtiment, et les passages de l’un à l’autre sont fréquents au cours d’une carrière.

Les qualités attendues

• Exigence sur la qualité du code : ici, un défaut a des conséquences de sécurité
• Goût du détail : les vulnérabilités naissent dans les cas limites
• Culture de la menace : savoir ce que l’on cherche à contrer, concrètement
• Rigueur de test : tester les entrées hostiles autant que les cas nominaux
• Sens de la performance : un produit trop coûteux en ressources est désactivé
• Humilité : accepter la revue de code croisée comme une nécessité, pas une critique
• Endurance : maintenir un produit sur plusieurs années, y compris son code hérité
• Curiosité : les techniques d’attaque évoluent, le produit doit suivre

Comment accède-t-on à ce métier ?

Le Panorama de l’ANSSI indique un niveau Bac+3 à Bac+5 avec une spécialisation en développement sécurisé, et cite le développement logiciel et l’ingénierie logicielle parmi les compétences cœur de métier. L’ordre des priorités est clair.

La voie naturelle : depuis le développement

Un développeur expérimenté dispose déjà de l’essentiel : conception, rigueur, culture du test, capacité à maintenir un code dans la durée. Ce qu’il doit construire, c’est la connaissance des menaces et des techniques d’attaque. Plusieurs mois d’investissement sérieux suffisent souvent à rendre cette bascule crédible.

Depuis la sécurité : plus difficile

Un profil cyber sans expérience de développement professionnelle part de beaucoup plus loin. Écrire du code de production robuste, maintenable et performant est une compétence à part entière, qui ne s’acquiert pas en accompagnement d’un autre métier.

Une reconversion simultanée depuis zéro en programmation et en cybersécurité est irréaliste. Mieux vaut devenir développeur d’abord, exercer, puis se spécialiser.

Où exerce-t-on ce métier ?

La France dispose d’un tissu réel d’éditeurs de sécurité, ce qui rend ce métier plus accessible qu’on ne l’imagine — nettement plus, en tout cas, que des métiers voisins comme cryptologue ou évaluateur. Les éditeurs recherchent d’ailleurs souvent des développeurs solides qu’ils formeront eux-mêmes à la sécurité.

Avantages et contraintes du métier

• Métier de construction : on fabrique un produit utilisé par d’autres
• Exigence technique élevée et stimulante
• Reste proche du code, pour qui ne veut pas quitter la technique
• Reconversion naturelle et rapide depuis le développement
• Peu d’astreintes en régime courant
• Passerelles vers la recherche, la cryptographie ou l’architecture logicielle

• Pression forte sur la qualité : un défaut est un problème de sécurité
• Maintenance de code hérité, parfois ancien et contraint
• Épisodes d’urgence lors de la publication d’une vulnérabilité produit
• Contraintes de performance et de compatibilité parfois frustrantes
• Veille technique lourde, les menaces évoluant en permanence
• Nombre d’employeurs plus limité que pour le développement généraliste