Tous les articles

Blog

Formation développement sécurisé : le score ne dit pas la vigilance

Formation développement sécurisé : PortSwigger, Juice Shop, Secure Code Warrior, salle. Ce que chaque option mesure, et ce qu'elle ne voit pas en revue.

  • Par Azziz ERRIME
  • 11 min de lecture
Table de relecture vue de haut, une seule pile de feuilles éclairée par une lampe

TL;DR

  • Une formation développement sécurisé se juge à ce que font les développeurs sans consigne, et aucune des options comparées ne le mesure en revue réelle.
  • Dans une expérience publiée en 2022, demander aux relecteurs de se concentrer sur la sécurité multipliait par huit la détection des vulnérabilités.
  • Je choisirais la plateforme pour ce qu’elle enseigne à l’équipe, et je mesurerais la vigilance en plus, dans les vraies revues de code.

Dans une expérience publiée en 2022, des chercheurs font relire une modification de code vulnérable à 150 développeurs, en ne demandant qu’à certains de penser à la sécurité. Ces derniers détectent les failles huit fois plus souvent. Toute formation développement sécurisé bute sur ce résultat : elle mesure ce que les développeurs savent faire quand on le leur demande.

Larissa Braz, Christian Aeberhard, Gül Çalikli et Alberto Bacchelli recrutent 150 développeurs, dont 71 % déclarent au moins trois ans d’expérience professionnelle. Chacun reçoit une modification de code à relire, comme celles qui passent tous les jours dans une pull request, et ce changement contient des vulnérabilités. Certains participants lisent une consigne de plus, se concentrer sur la sécurité, et d’autres reçoivent aussi une liste de contrôle. Puis chacun décide, seul devant le code, ce qu’il signale.

Le résultat est présenté à la conférence ICSE en 2022. Leur article le résume ainsi : « simply asking reviewers to focus on security during the code review increases eight times the probability of vulnerability detection ». La liste de contrôle, même adaptée au changement relu, n’ajoute rien de significatif. Les auteurs rappellent au passage que les développeurs « often miss even popular and easy-to-detect vulnerabilities during code review ».

Les relecteurs sans consigne n’avaient aucune raison d’être moins compétents que les autres. Ils regardaient simplement ailleurs, une situation que les formations comparées plus bas ne reproduisent pas.

L’attention du relecteur pèse plus que ce qu’il sait

Les auteurs parlent d’hypothèse de « l’attitude mentale » : le relecteur trouve ce qu’il cherche, et il cherche ce qu’on lui a demandé de chercher. La revue de code, ce moment où un développeur relit le changement d’un collègue avant qu’il rejoigne le code commun, porte d’abord sur la logique, les noms, les tests. La sécurité y entre quand quelqu’un l’y fait entrer.

Concrètement, une faille d’injection dans une pull request ressemble à une ligne ordinaire. Une variable passe d’un formulaire à une requête sans être filtrée, et rien ne la signale à l’œil qui vérifie que la fonctionnalité marche. Le relecteur qui sait reconnaître une injection la laisse passer s’il ne la cherche pas. L’attaquant, lui, ne cherche que ça : il repère les champs qui acceptent une saisie et suit la donnée jusqu’à la base.

Or les plateformes comparées plus bas posent la question à la place du relecteur : voici du code, trouvez la faille. C’est exactement la consigne donnée à une partie des relecteurs de l’expérience. Une formation développement sécurisé peut donc faire progresser le savoir sans rien dire de l’attention.

Les plateformes de formation développement sécurisé mesurent surtout une performance sur consigne

Dans ce tableau des options de formation sécurité applicative, je ne reprends que ce que les éditeurs ou la presse spécialisée publient. La ligne « salle » décrit l’usage courant, pas un éditeur.

Option Ce qu’on y fait Ce qui est mesuré et remonté Le développeur sait-il qu’il est évalué ?
PortSwigger Web Security Academy Labs d’attaque d’applications web, par exemple 30 sur le cross-site scripting Labs résolus, progression, classement Hall of Fame ; l’Academy est gratuite Oui
OWASP Juice Shop Défis sur une application volontairement vulnérable, gratuite et open source Tableau de score des défis Oui
Snyk Learn Leçons et parcours, gratuits Pourcentage de complétion Oui
Security Journey Parcours de formation au code sécurisé, sur devis Évaluations, rapports vers le LMS (SCORM, xAPI) Oui
Secure Code Warrior Défis sur du code Trust Score par développeur ; Trust Agent: AI relie les commits réels aux outils d’IA utilisés Oui pour la formation, en partie pour les commits suivis
Immersive (Developer AI Ranges) Pull requests et tri d’un backlog face à des agents de code Ce qui a été détecté ou manqué, avec un verdict de référence Oui, l’exercice est annoncé
Formation en salle Cours et travaux pratiques avec un formateur Feuille d’émargement, évaluation de fin de session Oui

Chacune a son point fort : PortSwigger apprend la mécanique des attaques web sans coûter un euro. OWASP Juice Shop, gratuit et open source, sert de terrain d’atelier. Snyk Learn propose des leçons et des parcours, gratuits eux aussi. Security Journey branche ses résultats sur l’outil de suivi des formations de l’entreprise. Secure Code Warrior fait relever des défis sur du code. La formation en salle permet de poser des questions à un formateur pendant les travaux pratiques.

Immersive va le plus loin vers le réel. Depuis le 29 juillet 2026, ses Developer AI Ranges placent les développeurs face à des pull requests et à des agents de code. Chaque exercice se conclut par un verdict de référence sur « what was caught or missed ». C’est l’approche publique la plus proche d’une vraie revue que j’aie trouvée. Le développeur sait pourtant qu’il est dans un exercice. Seul Trust Agent: AI, chez Secure Code Warrior, regarde des commits réels. Il croise le Trust Score et l’usage de l’IA avec des vulnérabilités, mais ne dit pas ce que la revue a laissé passer.

Si aucune de ces mesures n’observe la revue elle-même, que regarde l’auditeur quand il contrôle la formation sécurité des développeurs ?

Stand de tir forain aux cibles touchées au centre, une cible renversée dans l’ombre

Les cibles annoncées sont touchées en plein centre. Celle du quotidien attend dans l’ombre.

L’audit valide la formation sans voir la revue du lundi

Prenez PCI DSS, la norme de sécurité des cartes de paiement. Son exigence 6.2.2 impose aux développeurs de logiciels sur mesure une formation à la sécurité au moins une fois tous les 12 mois. Pour la contrôler, l’évaluateur suit une procédure précise, la 6.2.2.b : « Examine training records and interview personnel ». Il lit les registres et il interroge les équipes.

Le registre dit qui a suivi quelle formation, à quelle date, avec quel score. C’est précisément ce que remontent les plateformes du tableau, chez Security Journey par exemple, directement dans l’outil de gestion des formations. Rien, dans ce circuit, ne regarde ce qu’est devenue la dernière pull request qui touchait à une requête en base.

Je ne reproche rien à ce circuit, qui prouve qu’une formation a eu lieu, ce qu’on lui demande. Le risque vient de ce qu’on en déduit : un taux de complétion de 100 % rassure le comité de direction sur une compétence que personne n’a observée en situation. L’écart se creuse avec l’IA, qui augmente le volume de code à relire, comme je l’expliquais dans un précédent article sur la revue de code.

Reste l’objection la plus solide : certaines plateformes affirment justement mesurer un effet sur les vulnérabilités, pas seulement une présence.

Une baisse des vulnérabilités après une formation développement sécurisé ne dit pas d’où vient la vigilance

Secure Code Warrior a publié le 15 octobre 2024 une étude, présentée par CyberScoop, qui porte sur les données de 600 clients entreprise. Dans les organisations de plus de 7 000 développeurs suivant un même programme, l’éditeur mesure de 47 à 53 % de vulnérabilités en moins.

Je la prends au sérieux, parce qu’elle mesure un résultat, des vulnérabilités, là où beaucoup d’études de formation s’arrêtent à la satisfaction. C’est aussi une étude de l’éditeur, sur les données de sa propre plateforme, et les documents publics que j’ai pu lire ne détaillent pas comment les vulnérabilités ont été comptées. Elle peut être juste et ne pas répondre pour autant à la question de cet article.

Une baisse des failles dans le code d’une grande organisation formée mélange plusieurs causes : de meilleurs réflexes d’écriture, des outils d’analyse mieux réglés, des revues plus attentives. L’étude ne permet pas de dire laquelle a joué. Or la vigilance en revue est justement la part qu’aucune ligne du tableau n’observe dans la revue elle-même.

La formation développement sécurisé reste donc nécessaire : sans elle, personne ne sait à quoi ressemble une injection au milieu d’une pull request. Reste à la compléter par une mesure de ce qui se passe hors exercice.

La ligne sécurité dans le modèle de pull request est le geste le moins cher

On apprend sur la plateforme qui colle le mieux à la pile technique de l’équipe. On mesure ailleurs, dans le travail réel, ce que la revue laisse passer. Pour une équipe, voici ce que je ferais, dans cet ordre :

  • commencer par les ressources gratuites, PortSwigger, Juice Shop et Snyk Learn, pour voir ce qui accroche l’équipe avant de signer un contrat ;
  • choisir la plateforme payante sur vos langages et vos frameworks, pas sur la taille de son catalogue ;
  • demander à l’éditeur ce qui s’exporte : un taux de complétion, ou des résultats par compétence que vous pouvez croiser avec vos revues ;
  • suivre à part ce que la revue laisse passer, en reliant chaque faille trouvée plus tard, par un test ou en production, à la revue qui l’a vue passer ;
  • ajouter au modèle de pull request une ligne qui demande si la sécurité a été relue.

Cette dernière ligne est le geste le moins cher, et le plus proche de la consigne testée en 2022. Je ne sais pas encore s’il garde son effet une fois devenu routinier.

Je le précise : j’anime des formations et je mesure ce type d’écart, ce que les développeurs laissent passer quand ils relisent du code écrit par une IA. La formation leur donne le vocabulaire. Je cherche à savoir quand ils s’en servent sans qu’on le leur demande.

Poste d’aiguillage ferroviaire vide, un levier marqué d’un ruban rouge

Le geste qui compte se joue au poste, au moment où le train passe.

Le relecteur sans consigne, c’est votre équipe un lundi matin

Je reviens aux 150 développeurs de l’expérience. Ceux qui n’avaient pas reçu de consigne ressemblent trait pour trait à vos équipes un lundi matin, avec une file de pull requests à vider avant la réunion. Ils ont peut-être appris à reconnaître une faille, mais personne ne leur a demandé de la chercher à ce moment-là.

Une formation développement sécurisé bien choisie leur apprend quoi chercher. Aucune ne garantit qu’ils chercheront. Je ne choisirais donc pas une plateforme sur son catalogue ni sur le score moyen qu’elle affiche. En face de chaque euro de formation, je mettrais une mesure de ce qui passe la revue réelle.

Je garde un doute sur un point : dès qu’un développeur sait qu’on regarde ses revues, il relit mieux. Le code y gagne, et la mesure y perd, puisqu’elle redevient une consigne. Je n’ai pas encore trouvé comment observer la vigilance sans la changer.

Questions fréquentes sur la formation développement sécurisé

C’est quoi le secure coding ?

Le secure coding, ou développement sécurisé, regroupe les pratiques qui évitent d’introduire des failles en écrivant le code : valider les entrées, contrôler les accès, choisir des dépendances sûres. La norme PCI DSS en fait un sujet de formation obligatoire pour les développeurs de logiciels sur mesure. Son exigence 6.2.2 impose une formation au moins tous les 12 mois, qui couvre notamment les « secure coding techniques ».

Quelle formation pour la sécurité des développeurs ?

Pour une première formation développement sécurisé sans budget, la Web Security Academy de PortSwigger est entièrement gratuite, comme OWASP Juice Shop et Snyk Learn. Les plateformes payantes ajoutent notamment des évaluations et des rapports pour le suivi des formations. Dans tous les cas, mesurez à part ce qui passe vos revues de code, où une simple consigne de sécurité change nettement la détection, selon Braz et ses collègues.

Existe-t-il une formation OWASP gratuite ?

Oui, OWASP Juice Shop, projet de la fondation OWASP publié sous licence MIT, est une application volontairement vulnérable dont les défis se suivent sur un tableau de score. Pour un parcours plus guidé, la Web Security Academy de PortSwigger, gratuite elle aussi, couvre les grandes familles de failles web.

Secure Code Warrior, c’est quoi ?

Secure Code Warrior est une plateforme de formation au code sécurisé qui attribue à chaque développeur un Trust Score. Depuis mars 2026, son module Trust Agent: AI relie les commits aux outils d’IA qui les ont influencés, selon Help Net Security. Une étude de l’éditeur publiée en octobre 2024 revendique 47 à 53 % de vulnérabilités en moins dans les grandes organisations formées.

Sources