À quoi ressemble un SDLC sécurisé ?
Réponse courte
Un SDLC sécurisé intègre la sécurité à chaque phase au lieu de tester à la fin : exigences (cas de sécurité et d'abus), conception (modélisation des menaces), implémentation (standards de codage sécurisé, SAST/SCA dans l'IDE et la CI), tests (DAST, pentest), publication (gates et validation) et exploitation (surveillance, patching, feedback). Le shift-left déplace les défauts plus tôt, là où ils sont peu coûteux à corriger ; des modèles de maturité comme OWASP SAMM et BSIMM mesurent à quel point vous le faites réellement.
Un SDLC sécurisé signifie que la sécurité est une propriété de la façon dont vous construisez le logiciel, pas un scan que vous lancez la semaine avant le lancement. Les recruteurs interrogent dessus pour jauger si vous savez opérationnaliser le « shift-left » — déplacer la découverte des défauts plus tôt, là où une correction coûte un commentaire de code au lieu d'un incident.
La sécurité dans chaque phase
- Exigences. Capturer les exigences de sécurité et les cas d'abus à côté des fonctionnalités — « ce que cela ne doit jamais permettre » est aussi important que « ce que cela doit faire ».
- Conception. Modéliser les menaces de l'architecture et choisir des patterns sécurisés avant qu'aucun code n'existe. Le bug le moins coûteux à corriger est celui qu'on ne construit jamais.
- Implémentation. Standards de codage sécurisé, plus SAST et SCA (analyse de composition logicielle/dépendances) automatisés tournant dans l'IDE et à chaque pull request pour un feedback immédiat.
- Tests. DAST, fuzzing et tests d'intrusion manuels ciblés contre les builds en cours d'exécution.
- Publication. Gates de sécurité et validation — mais ajustées au risque, pour qu'un constat informatif de faible gravité ne bloque pas un déploiement alors qu'un constat critique le fait.
- Exploitation. Surveillance en runtime, patching, hygiène des secrets et de la configuration, et réinjection des incidents dans les exigences et les modèles de menace.
Pourquoi le shift-left fonctionne
Le coût de correction d'un défaut grimpe fortement plus il est trouvé tard. Attraper une faille d'injection dans une vérification SAST de pull request coûte quelques minutes ; l'attraper sous forme de violation coûte divulgation, indisponibilité et confiance. Le shift-left déplace simplement le point de découverte là où la remédiation est peu coûteuse.
Mesurer la maturité
On gère ce que l'on mesure. OWASP SAMM est un modèle de maturité prescriptif et auto-évaluable couvrant gouvernance, conception, implémentation, vérification et exploitation. BSIMM est descriptif — il rapporte ce que font réellement de vraies entreprises, afin de vous comparer à vos pairs.
Ce que recherchent les recruteurs
Ils veulent des points de contact concrets par phase, le bon outil au bon endroit (SAST tôt, DAST sur les applications en cours d'exécution, SCA pour les dépendances), des gates ajustées au risque plutôt que des bloqueurs systématiques, et la conscience qu'un modèle de maturité transforme « on se soucie de la sécurité » en quelque chose de mesurable.
Questions de suivi probables
- Quelle est la différence entre SAST, DAST et SCA, et où chacun s'inscrit-il ?
- En quoi OWASP SAMM et BSIMM diffèrent-ils dans leur objectif ?
- Comment ajoutez-vous une gate de sécurité à la CI sans bloquer chaque déploiement ?