La sécurité dans Scrum : décaler la sécurité applicative vers la gauche
Le modèle traditionnel — test de pénétration juste avant la mise en production — présente des problèmes bien connus : les vulnérabilités découvertes tardivement sont bien plus coûteuses à corriger, les travaux de remédiation perturbent les engagements de Sprint, et la sécurité devient la dernière préoccupation de l'équipe. Le décalage à gauche signifie intégrer la sécurité à trois niveaux : le backlog produit (modélisation des menaces, exigences de sécurité), le Sprint (pratiques de codage sécurisé, tests automatisés), et la Définition de Fini (critères de sécurité obligatoires).
Pratiques concrètes pour les équipes Scrum
Modélisation des menaces (STRIDE) au Sprint Zéro ou à l'inception d'une fonctionnalité.
Standards de codage sécurisé dans la Définition de Fini.
SAST (analyse statique du code) intégré dans le pipeline CI — retour immédiat à chaque commit.
SCA (analyse de composition logicielle) pour les dépendances open source — analyse automatique à chaque build.
Critères d'acceptation de sécurité dans les user stories touchant authentification, autorisation ou données sensibles.
Un Champion de la Sécurité — un développeur avec des responsabilités de sécurité étendues — est le tissu conjonctif entre l'équipe et l'organisation de sécurité. Les organisations qui disposent de tels champions signalent des temps de remédiation plus rapides et une sensibilisation à la sécurité plus élevée dans leurs équipes de développement.
Si vos équipes de développement constatent que la sécurité est systématiquement une source de retravail tardif et de retards de publication, le conseil en exécution de programmes et de projets de XNM peut vous aider à construire un programme de sécurité décalé à gauche qui s'intègre à vos pratiques Scrum plutôt que d'y ajouter une charge.