Avant d’examiner ce que les auditeurs doivent v\u00e9rifier \u00e0 chaque phase, il convient d’\u00e9tablir ce qu’est r\u00e9ellement un cycle de vie de d\u00e9veloppement logiciel s\u00e9curis\u00e9 (Secure SDLC), pourquoi il compte dans les environnements r\u00e9glement\u00e9s et en quoi il diff\u00e8re des concepts voisins. Cette introduction pose ces bases.<\/p>\n
Les applications d’entreprise modernes \u00e9voluent dans des environnements o\u00f9 les d\u00e9faillances de s\u00e9curit\u00e9 ne se limitent plus \u00e0 des incidents techniques. Elles se traduisent directement par des constats r\u00e9glementaires, des perturbations op\u00e9rationnelles, des sanctions financi\u00e8res et des atteintes \u00e0 la r\u00e9putation.<\/p>\n
Dans les secteurs r\u00e9glement\u00e9s tels que la banque, l’assurance, la sant\u00e9 et les infrastructures critiques, la s\u00e9curit\u00e9 applicative n’est pas facultative. Elle doit \u00eatre syst\u00e9matique, d\u00e9montrable et auditable<\/strong> tout au long du cycle de vie de d\u00e9veloppement logiciel. C’est l\u00e0 que le SDLC s\u00e9curis\u00e9 devient un concept fondateur — non pas un outil, une liste de contr\u00f4le ou un simple scan de s\u00e9curit\u00e9, mais une approche structur\u00e9e visant \u00e0 int\u00e9grer des contr\u00f4les de s\u00e9curit\u00e9, une gouvernance et la production de preuves tout au long de la vie d’une application, de la conception \u00e0 la production et au-del\u00e0.<\/p>\n Un SDLC s\u00e9curis\u00e9 est une extension du cycle de vie de d\u00e9veloppement logiciel traditionnel qui int\u00e8gre des exigences, des contr\u00f4les et des activit\u00e9s de v\u00e9rification de s\u00e9curit\u00e9 \u00e0 chaque \u00e9tape de la livraison. Plut\u00f4t que de traiter la s\u00e9curit\u00e9 comme un ultime point de contr\u00f4le ou une activit\u00e9 post\u00e9rieure \u00e0 la mise en production, il garantit que la s\u00e9curit\u00e9 est :<\/p>\n Dans les environnements r\u00e9glement\u00e9s, le SDLC s\u00e9curis\u00e9 sert \u00e9galement de socle pour d\u00e9montrer la conformit\u00e9 \u00e0 des r\u00e9f\u00e9rentiels tels qu’ISO 27001, SOC 2, DORA, NIS2 et PCI DSS.<\/p>\n Trois principes sous-tendent un SDLC s\u00e9curis\u00e9 mature :<\/p>\n Ces termes sont souvent employ\u00e9s de mani\u00e8re interchangeable, mais ils r\u00e9pondent \u00e0 des finalit\u00e9s diff\u00e9rentes :<\/p>\n Le SDLC s\u00e9curis\u00e9 fournit le socle structurel sur lequel reposent les pratiques DevSecOps et les m\u00e9canismes de s\u00e9curit\u00e9 CI\/CD.<\/p>\n Dans les environnements r\u00e9glement\u00e9s, le SDLC s\u00e9curis\u00e9 s’accompagne de contraintes suppl\u00e9mentaires : les contr\u00f4les doivent \u00eatre document\u00e9s et tra\u00e7ables, les d\u00e9cisions doivent \u00eatre justifiables aupr\u00e8s des auditeurs, les exceptions doivent \u00eatre explicites, approuv\u00e9es et enregistr\u00e9es, et les preuves doivent \u00eatre conserv\u00e9es et exportables. Cela transforme le SDLC s\u00e9curis\u00e9, d’une pratique purement technique, en un syst\u00e8me de gouvernance et de gestion des risques.<\/p>\n Il s’ensuit qu’un SDLC s\u00e9curis\u00e9 ne peut pas simplement s’acheter. Les outils le soutiennent mais ne le d\u00e9finissent pas ; sans objectifs de contr\u00f4le clairs, sans flux de travail appliqu\u00e9s, sans mod\u00e8les de gouvernance et sans strat\u00e9gies de conservation des preuves, m\u00eame les outils les plus avanc\u00e9s ne parviennent pas \u00e0 produire de v\u00e9ritables r\u00e9sultats en mati\u00e8re de s\u00e9curit\u00e9 ou de conformit\u00e9. Le SDLC s\u00e9curis\u00e9 est un mod\u00e8le op\u00e9rationnel, pas un produit. Les organisations qui le mettent en \u0153uvre correctement gagnent en rapidit\u00e9 d’audit, subissent moins d’incidents en production, r\u00e9duisent les frictions entre les fonctions s\u00e9curit\u00e9, d\u00e9veloppement et conformit\u00e9, et accroissent leur confiance dans la livraison logicielle. L’objectif n’est pas d’ajouter davantage de s\u00e9curit\u00e9, mais de rendre la s\u00e9curit\u00e9 incontournable, v\u00e9rifiable et p\u00e9renne.<\/p>\n Ces bases \u00e9tant pos\u00e9es, le reste de ce guide examine le SDLC s\u00e9curis\u00e9 en tant que cadre de contr\u00f4le et d\u00e9taille ce que les auditeurs doivent v\u00e9rifier \u00e0 chaque phase.<\/p>\n Le cycle de vie de d\u00e9veloppement logiciel s\u00e9curis\u00e9 (Secure SDLC) est souvent pr\u00e9sent\u00e9 comme une m\u00e9thodologie de d\u00e9veloppement — une s\u00e9quence de pratiques que les \u00e9quipes d’ing\u00e9nierie suivent pour concevoir des logiciels plus s\u00fbrs. Pour les auditeurs et les responsables conformit\u00e9, toutefois, il devrait \u00eatre \u00e9valu\u00e9 comme quelque chose de plus fondamental : un cadre de contr\u00f4le<\/strong>.<\/p>\n Chaque phase du SDLC repr\u00e9sente un point de contr\u00f4le o\u00f9 des activit\u00e9s de s\u00e9curit\u00e9 sp\u00e9cifiques doivent se d\u00e9rouler, des preuves sp\u00e9cifiques doivent \u00eatre g\u00e9n\u00e9r\u00e9es et des r\u00e9sultats sp\u00e9cifiques doivent \u00eatre v\u00e9rifiables. Lorsqu’une organisation affirme op\u00e9rer un SDLC s\u00e9curis\u00e9, les auditeurs doivent regarder au-del\u00e0 de la documentation de processus et \u00e9valuer si les contr\u00f4les fonctionnent r\u00e9ellement \u00e0 chaque phase.<\/p>\n Ce guide parcourt chaque phase du SDLC du point de vue de l’auditeur, en pr\u00e9cisant ce qui devrait se passer, quelles preuves demander, \u00e0 quoi ressemble une bonne pratique et ce qui devrait susciter des inqui\u00e9tudes.<\/p>\n Les consid\u00e9rations de s\u00e9curit\u00e9 sont int\u00e9gr\u00e9es \u00e0 la planification du projet avant le d\u00e9but de tout d\u00e9veloppement. Cela inclut la mod\u00e9lisation des menaces pour identifier les vecteurs d’attaque potentiels, la d\u00e9finition des exigences de s\u00e9curit\u00e9 en parall\u00e8le des exigences fonctionnelles, et la classification de l’application selon le cadre de classification des risques de l’organisation.<\/p>\n Les d\u00e9veloppeurs suivent des normes de codage s\u00e9curis\u00e9 document\u00e9es. Les modifications de code sont revues au regard des enjeux de s\u00e9curit\u00e9 — soit par revue par les pairs avec des relecteurs sensibilis\u00e9s \u00e0 la s\u00e9curit\u00e9, soit par test statique de s\u00e9curit\u00e9 applicative (SAST) automatis\u00e9. La d\u00e9tection de secrets emp\u00eache que des identifiants, des cl\u00e9s d’API et des jetons soient enregistr\u00e9s dans les d\u00e9p\u00f4ts.<\/p>\n Le processus de build inclut l’analyse de composition logicielle (SCA) pour identifier les vuln\u00e9rabilit\u00e9s des d\u00e9pendances tierces et open source. Une nomenclature logicielle (SBOM) est g\u00e9n\u00e9r\u00e9e pour chaque build afin de tenir \u00e0 jour un inventaire de tous les composants. Les artefacts de build sont sign\u00e9s pour garantir leur int\u00e9grit\u00e9 et pr\u00e9venir toute alt\u00e9ration.<\/p>\n Le test dynamique de s\u00e9curit\u00e9 applicative (DAST) est r\u00e9alis\u00e9 sur des applications en cours d’ex\u00e9cution afin d’identifier des vuln\u00e9rabilit\u00e9s que l’analyse statique ne peut d\u00e9tecter (failles d’authentification, probl\u00e8mes de configuration, vuln\u00e9rabilit\u00e9s d’injection \u00e0 l’ex\u00e9cution). Les tests d’intrusion men\u00e9s par du personnel qualifi\u00e9 apportent une perspective adverse. Les environnements de test sont isol\u00e9s de la production afin de pr\u00e9venir toute fuite de donn\u00e9es.<\/p>\n Les mises en production sont soumises \u00e0 des flux d’approbation qui v\u00e9rifient que toutes les activit\u00e9s de s\u00e9curit\u00e9 requises ont \u00e9t\u00e9 men\u00e9es \u00e0 bien. Des points de contr\u00f4le de politique (policy gates) dans le pipeline de livraison imposent que les exigences de s\u00e9curit\u00e9 soient satisfaites avant que le code ne puisse progresser vers la production. Les d\u00e9cisions de mise en production sont document\u00e9es dans le cadre de la gestion des changements.<\/p>\n Les d\u00e9ploiements sont journalis\u00e9s avec un niveau de d\u00e9tail suffisant pour \u00e9tablir ce qui a \u00e9t\u00e9 d\u00e9ploy\u00e9, quand, par qui et vers quel environnement. La configuration est valid\u00e9e par rapport aux r\u00e9f\u00e9rentiels de s\u00e9curit\u00e9. Les environnements de production correspondent aux configurations qui ont \u00e9t\u00e9 test\u00e9es.<\/p>\n Les applications en production sont surveill\u00e9es pour d\u00e9tecter les \u00e9v\u00e9nements de s\u00e9curit\u00e9, les comportements anormaux et les nouvelles vuln\u00e9rabilit\u00e9s. Des m\u00e9canismes de protection \u00e0 l’ex\u00e9cution d\u00e9tectent les menaces actives et y r\u00e9pondent. Un processus de divulgation de vuln\u00e9rabilit\u00e9s permet aux chercheurs externes de signaler les probl\u00e8mes de mani\u00e8re responsable.<\/p>\n D’apr\u00e8s les r\u00e9sultats d’audit typiques dans les organisations r\u00e9glement\u00e9es, les constats les plus fr\u00e9quents comprennent :<\/p>\n Les auditeurs peuvent utiliser un mod\u00e8le de maturit\u00e9 pour caract\u00e9riser la qualit\u00e9 de mise en \u0153uvre du SDLC s\u00e9curis\u00e9. Cela aide \u00e0 formuler les constats et les recommandations de mani\u00e8re proportionn\u00e9e.<\/p>\n Pour des ressources connexes, voir :<\/p>\nQu’est-ce qu’un SDLC s\u00e9curis\u00e9 ?<\/h3>\n
\n
Principes fondamentaux<\/h3>\n
\n
SDLC s\u00e9curis\u00e9, DevSecOps et s\u00e9curit\u00e9 CI\/CD<\/h3>\n
\n
Un syst\u00e8me de gouvernance, pas un produit<\/h3>\n
Le SDLC s\u00e9curis\u00e9 en tant que cadre de contr\u00f4le<\/h2>\n
Phase PLAN<\/h2>\n
Ce qui devrait se passer<\/h3>\n
Preuves \u00e0 demander<\/h3>\n
\n
\u00c0 quoi ressemble une bonne pratique<\/h3>\n
\n
\u00c0 quoi ressemble une mauvaise pratique<\/h3>\n
\n
Phase CODE<\/h2>\n
Ce qui devrait se passer<\/h3>\n
Preuves \u00e0 demander<\/h3>\n
\n
\u00c0 quoi ressemble une bonne pratique<\/h3>\n
\n
\u00c0 quoi ressemble une mauvaise pratique<\/h3>\n
\n
Phase BUILD<\/h2>\n
Ce qui devrait se passer<\/h3>\n
Preuves \u00e0 demander<\/h3>\n
\n
\u00c0 quoi ressemble une bonne pratique<\/h3>\n
\n
\u00c0 quoi ressemble une mauvaise pratique<\/h3>\n
\n
Phase TEST<\/h2>\n
Ce qui devrait se passer<\/h3>\n
Preuves \u00e0 demander<\/h3>\n
\n
\u00c0 quoi ressemble une bonne pratique<\/h3>\n
\n
\u00c0 quoi ressemble une mauvaise pratique<\/h3>\n
\n
Phase RELEASE<\/h2>\n
Ce qui devrait se passer<\/h3>\n
Preuves \u00e0 demander<\/h3>\n
\n
\u00c0 quoi ressemble une bonne pratique<\/h3>\n
\n
\u00c0 quoi ressemble une mauvaise pratique<\/h3>\n
\n
Phase DEPLOY<\/h2>\n
Ce qui devrait se passer<\/h3>\n
Preuves \u00e0 demander<\/h3>\n
\n
\u00c0 quoi ressemble une bonne pratique<\/h3>\n
\n
\u00c0 quoi ressemble une mauvaise pratique<\/h3>\n
\n
Phase MONITOR<\/h2>\n
Ce qui devrait se passer<\/h3>\n
Preuves \u00e0 demander<\/h3>\n
\n
\u00c0 quoi ressemble une bonne pratique<\/h3>\n
\n
\u00c0 quoi ressemble une mauvaise pratique<\/h3>\n
\n
Synth\u00e8se : contr\u00f4les, preuves et signaux d’alerte par phase<\/h2>\n
\n\n
\n \nPhase<\/th>\n Contr\u00f4le cl\u00e9<\/th>\n Preuve produite<\/th>\n O\u00f9 la trouver<\/th>\n Signal d’alerte<\/th>\n<\/tr>\n<\/thead>\n \n PLAN<\/td>\n Mod\u00e9lisation des menaces<\/td>\n Document de mod\u00e8le de menaces<\/td>\n Wiki, d\u00e9p\u00f4t de conception, registre des risques<\/td>\n Aucun mod\u00e8le de menaces, ou mod\u00e8les jamais mis \u00e0 jour<\/td>\n<\/tr>\n \n CODE<\/td>\n SAST \/ revue de code<\/td>\n R\u00e9sultats de scans, enregistrements de revue<\/td>\n Journaux du pipeline CI\/CD, outil de revue de code<\/td>\n SAST non int\u00e9gr\u00e9 ou r\u00e9sultats ignor\u00e9s<\/td>\n<\/tr>\n \n BUILD<\/td>\n SCA \/ SBOM<\/td>\n R\u00e9sultats de scans de d\u00e9pendances, fichiers SBOM<\/td>\n Syst\u00e8me de build, d\u00e9p\u00f4t d’artefacts<\/td>\n Aucun inventaire de composants pour la production<\/td>\n<\/tr>\n \n TEST<\/td>\n DAST \/ tests d’intrusion<\/td>\n Rapports de scans, rapports de tests d’intrusion<\/td>\n Outils de test de s\u00e9curit\u00e9, archive de rapports<\/td>\n Aucun test dynamique ou aucune ind\u00e9pendance<\/td>\n<\/tr>\n \n RELEASE<\/td>\n Points de contr\u00f4le de politique \/ approbation<\/td>\n R\u00e9sultats des points de contr\u00f4le, enregistrements d’approbation<\/td>\n Journaux du pipeline, syst\u00e8me de gestion des changements<\/td>\n Points de contr\u00f4le contourn\u00e9s sans approbation<\/td>\n<\/tr>\n \n DEPLOY<\/td>\n Journalisation des d\u00e9ploiements<\/td>\n Journaux de d\u00e9ploiement, v\u00e9rifications de configuration<\/td>\n Plateforme de d\u00e9ploiement, outils de surveillance<\/td>\n D\u00e9ploiements manuels sans piste d’audit<\/td>\n<\/tr>\n \n MONITOR<\/td>\n Surveillance \u00e0 l’ex\u00e9cution<\/td>\n Journaux d’alertes, enregistrements d’incidents<\/td>\n SIEM, plateforme de surveillance, gestion des tickets<\/td>\n Aucune surveillance au niveau applicatif<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Constats d’audit fr\u00e9quents \u00e0 travers les phases du SDLC<\/h2>\n
\n
\u00c9valuer la maturit\u00e9 du SDLC<\/h2>\n
\n\n
\n \nNiveau de maturit\u00e9<\/th>\n Caract\u00e9ristiques<\/th>\n Implications pour l’audit<\/th>\n<\/tr>\n<\/thead>\n \n Ad hoc (niveau 1)<\/strong><\/td>\n Les activit\u00e9s de s\u00e9curit\u00e9 sont men\u00e9es de mani\u00e8re incoh\u00e9rente, d\u00e9pendent de l’initiative individuelle et ne sont pas document\u00e9es dans une politique. Aucune automatisation.<\/td>\n Lacunes de contr\u00f4le fondamentales. Les constats seront nombreux et significatifs. Recommander l’\u00e9tablissement d’une politique et d’une gouvernance de base.<\/td>\n<\/tr>\n \n D\u00e9fini (niveau 2)<\/strong><\/td>\n Des politiques et proc\u00e9dures existent. Les activit\u00e9s de s\u00e9curit\u00e9 sont document\u00e9es et attribu\u00e9es. L’outillage est en place mais peut ne pas \u00eatre appliqu\u00e9 de mani\u00e8re coh\u00e9rente.<\/td>\n Les contr\u00f4les existent mais leur efficacit\u00e9 op\u00e9rationnelle peut \u00eatre faible. Se concentrer sur la v\u00e9rification d’une ex\u00e9cution coh\u00e9rente et de la qualit\u00e9 des preuves.<\/td>\n<\/tr>\n \n G\u00e9r\u00e9 (niveau 3)<\/strong><\/td>\n Les contr\u00f4les de s\u00e9curit\u00e9 sont appliqu\u00e9s de mani\u00e8re coh\u00e9rente, automatis\u00e9s lorsque possible et suivis au moyen d’indicateurs. La gouvernance est active.<\/td>\n Les contr\u00f4les fonctionnent efficacement. L’attention de l’audit se d\u00e9place vers les cas particuliers, les exceptions et l’am\u00e9lioration continue.<\/td>\n<\/tr>\n \n Optimis\u00e9 (niveau 4)<\/strong><\/td>\n Am\u00e9lioration continue fond\u00e9e sur des indicateurs. Identification proactive des menaces. La s\u00e9curit\u00e9 est pleinement int\u00e9gr\u00e9e \u00e0 la culture et \u00e0 l’outillage de d\u00e9veloppement. Automatisation avanc\u00e9e.<\/td>\n Confiance \u00e9lev\u00e9e dans l’environnement de contr\u00f4le. L’audit se concentre sur la p\u00e9rennit\u00e9, l’adaptation aux nouvelles menaces et la gouvernance des capacit\u00e9s avanc\u00e9es.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Pour aller plus loin<\/h2>\n
\n
Ressources connexes pour les auditeurs<\/h3>\n