Threat modeling intégré aux sprints Agile

Rituels STRIDE de 10 minutes intégrés au sprint planning pour faire remonter les bugs sécurité avant la QA.

AgileSTRIDEDevSecOpsCI/CD

Contexte

En encadrant une équipe produit distribuée, nous découvrions les failles sécurité après release car le ‘vrai travail’ primait. Il nous fallait une habitude reproductible tenant dans des sprints de deux semaines.

Menaces

  • Des user stories livrées sans cartographier la surface d’attaque.
  • Des intégrations SaaS poussées en prod sans revue.
  • Secrets qui dérivent entre environnements à coups de copier/coller.
  • Réponse à incident basée sur la mémoire tribale.

Approche

  1. Ajout de Security Acceptance Criteria sur toute story touchant auth, paiements ou PII ; la story restait ‘incomplète’.
  2. Huddles STRIDE de 10 minutes au kickoff : designers, devs, PM listent spoofing/tampering tant que c’est bon marché.
  3. Secret scanning, audit dépendances et SAST intégrés au CI ; les PR échouent vite avec remédiations actionnables.
  4. Playbooks d’incident et chemins de rollback légers pour que l’astreinte sache quoi faire dès qu’une alerte tombe.
  5. Suivi des findings dans Jira aux côtés du produit pour rendre la dette sécurité visible et estimable.

Résultats

En deux sprints, les escalades tardives ont chuté de 48 %, trois scopes OAuth mal configurés ont été détectés avant lancement et l’équipe a cessé de traiter l’AppSec comme une contrainte. Le rituel est resté car il coûte 10 minutes et économise des semaines.

Retours d’expérience

La culture sécurité prend quand elle ressemble à une revue de design, pas à un audit. De petits rituels prévisibles valent mieux qu’une checklist annuelle géante.

    Threat Modeling Inside Agile Sprints — Case Study