À quoi ressemble un SDLC sécurisé, et quelles activités de sécurité ont lieu à chaque phase ?

Un cycle de vie de développement logiciel (SDLC) sécurisé intègre la sécurité comme une activité continue tout au long du processus de développement plutôt qu'une porte à la fin. L'idée centrale est le shift left : plus un défaut est trouvé tôt, moins il coûte cher et plus il est facile à corriger — un défaut de conception détecté sur un tableau blanc ne coûte presque rien ; le même défaut trouvé en production après une intrusion est extrêmement coûteux.

La sécurité à chaque phase

• Exigences : capturez les exigences de sécurité et de conformité aux côtés des exigences fonctionnelles, et rédigez des cas d'abus — comment quelqu'un pourrait-il détourner cette fonctionnalité ? — et pas seulement des user stories.
• Conception : réalisez une modélisation des menaces (par exemple STRIDE) pour identifier comment le système pourrait être attaqué et concevez les contrôles en conséquence. Les décisions d'architecture comme les frontières de confiance et les flux d'authentification sont les moins chères à bien faire ici.
• Développement : suivez des standards de codage sécurisé, exécutez le SAST (analyse statique) dans l'IDE et la CI, et utilisez la SCA / analyse des dépendances pour repérer les bibliothèques tierces vulnérables — la plupart des applications modernes sont majoritairement le code d'autrui.
• Tests / QA : ajoutez le DAST (test dynamique contre l'application en cours d'exécution), le fuzzing et des tests d'intrusion ciblés avant la mise en production.
• Déploiement : analysez l'infrastructure-as-code et les images de conteneurs, gérez les secrets correctement, et durcissez la configuration d'exécution.
• Exploitation / maintenance : surveillance et journalisation continues, correctifs appliqués en temps voulu, et un plan de réponse aux incidents testé pour gérer ce qui passe entre les mailles. Les constats alimentent à nouveau les exigences.

Faire en sorte que ça marche

Automatisez les contrôles dans le pipeline CI/CD pour que la sécurité soit un retour rapide, pas un goulot d'étranglement manuel. Utilisez des portes basées sur le risque — faites échouer le build sur les constats critiques, avertissez sur les moins graves — pour que la sécurité facilite la livraison au lieu de la bloquer.

Ce que les recruteurs recherchent

Une réponse de niveau senior associe des activités spécifiques à des phases spécifiques (modélisation des menaces à la conception, SAST/SCA en développement, DAST/tests d'intrusion en QA, surveillance en exploitation), explique pourquoi le shift left fait économiser de l'argent, et montre une conscience de l'intégration de tout cela dans le pipeline sans paralyser la livraison.