01Ce qu'est un Secure SDLC – et pourquoi les tests seuls ne suffisent pas
Un SSDLC n'est pas un projet supplémentaire, mais une discipline de processus : les exigences, activités et responsabilités en matière de sécurité sont définies tout au long des phases du développement logiciel – des exigences à l'exploitation, en passant par la conception, l'implémentation, les tests et la mise en production. L'idée fondamentale est de prévenir ou de détecter les vulnérabilités le plus tôt possible, car leur correction devient plus coûteuse à chaque phase ultérieure (« shift left »). Les tests de sécurité ponctuels juste avant la mise en production restent importants, mais ils ne vérifient que le résultat ; un SSDLC s'attaque en plus aux causes au sein du processus. La démarche est indépendante du modèle de développement et s'intègre aussi bien dans des organisations classiques qu'agiles ou DevOps.
02NIST SSDF (SP 800-218) : le catalogue de référence des pratiques de développement sécurisé
Le Secure Software Development Framework du NIST (SP 800-218, version 1.1, finale depuis février 2022) décrit 19 practices avec 42 tasks réparties en quatre groupes : « Prepare the Organization » (PO), « Protect the Software » (PS), « Produce Well-Secured Software » (PW) et « Respond to Vulnerabilities » (RV). Chaque practice contient des exemples de mise en œuvre et des références vers d'autres normes, tout en étant volontairement formulée de manière neutre sur les plans technologique et méthodologique – le SSDF se prête ainsi à servir de langage commun entre le développement, la sécurité et les achats. Depuis le 17 décembre 2025, le projet de version 1.2 (SP 800-218r1, Initial Public Draft ; la période de commentaires s'est achevée le 30 janvier 2026) est également disponible ; il n'est pas encore finalisé et ne doit donc être considéré que comme une perspective.
03SP 800-218A : le profil SSDF pour l'IA générative
Pour le développement de l'IA générative et des « dual-use foundation models », le NIST a publié en juillet 2024 le complément SP 800-218A (« Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile »). Ce Community Profile étend les practices du SSDF avec des tâches, recommandations et références spécifiques à l'IA pour l'ensemble du cycle de vie du développement des modèles – par exemple pour le traitement des données d'entraînement et des artefacts de modèles. Il s'adresse aux organisations qui développent des modèles d'IA, les intègrent dans des systèmes ou les acquièrent, et il est expressément conçu pour être utilisé conjointement avec SP 800-218.
04OWASP SAMM : mesurer la maturité et en déduire une feuille de route
Tandis que le SSDF décrit ce qu'il faut faire, l'OWASP Software Assurance Maturity Model (SAMM, version 2 depuis janvier 2020, actuellement version 2.2 de juillet 2024) répond à la question de savoir dans quelle mesure une organisation le fait déjà. Le modèle s'articule en cinq business functions – Governance, Design, Implementation, Verification et Operations – comptant chacune trois security practices (15 au total), évaluées chacune selon deux streams et trois niveaux de maturité. SAMM est explicitement conçu comme un modèle mesurable et prend en compte, outre la couverture, la qualité des activités ; le résultat permet d'en déduire une feuille de route d'amélioration priorisée. VamiSec met à disposition un self-assessment SAMM sur ssdlc-assessment.com.
05Security gates : des points de contrôle définis pour chaque phase
Les security gates sont des critères définis à l'avance qu'un projet doit remplir avant de passer à la phase suivante – exactement ce qu'exige la practice SSDF PO.4 (« Define and Use Criteria for Software Security Checks »). Parmi les gates typiques : des exigences de sécurité documentées dans la phase d'expression des besoins (PO.1), un threat model lors de la conception (PW.1), des règles de codage sécurisé et des contrôles automatisés tels que SAST et Software Composition Analysis lors de l'implémentation (PW.5, PO.3), des revues de code et des tests de sécurité avant la mise en production (PW.7, PW.8), ainsi que des artefacts de build et de release protégés, à l'intégrité démontrable (PS.1, PS.2). En exploitation, l'identification continue des vulnérabilités, leur priorisation et l'analyse des causes racines (RV.1–RV.3) bouclent le cycle. Des critères de gate efficaces sont formulés de manière mesurable – par exemple via la part de gates franchis, le délai de correction des vulnérabilités détectées ou la récurrence des mêmes classes de vulnérabilités ; SAMM ancre ce pilotage dans la practice « Strategy & Metrics ».
06CRA : obligations de processus pour les produits comportant des éléments numériques
Le Cyber Resilience Act (règlement (UE) 2024/2847, en vigueur depuis décembre 2024) rend un SSDLC opérationnel obligatoire pour les fabricants de produits comportant des éléments numériques : l'annexe I, partie I, définit les exigences relatives aux propriétés des produits (notamment la security by design et des paramètres par défaut sécurisés sur la base d'une évaluation des risques), la partie II les exigences relatives au traitement des vulnérabilités – y compris l'établissement d'une Software Bill of Materials (SBOM). Les vulnérabilités activement exploitées et les incidents graves seront soumis à notification obligatoire à partir du 11 septembre 2026 (alerte précoce sous 24 heures, informations complémentaires sous 72 heures, rapport final après 14 jours ou un mois selon le cas) ; le règlement sera pleinement applicable à partir du 11 décembre 2027. Les mises à jour de sécurité doivent être fournies pendant une période de support en règle générale de cinq ans – sans processus documentés de développement et de traitement des vulnérabilités, cela peut difficilement être démontré de manière fiable.
