{"id":1269,"date":"2026-03-25T17:23:58","date_gmt":"2026-03-25T16:23:58","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/secure-sdlc-auditor-perspective-2\/"},"modified":"2026-03-26T00:11:55","modified_gmt":"2026-03-25T23:11:55","slug":"secure-sdlc-auditor-perspective","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/secure-sdlc-auditor-perspective\/","title":{"rendered":"Le Secure SDLC du point de vue de l’auditeur \u2014 Que v\u00e9rifier \u00e0 chaque phase"},"content":{"rendered":"

Le Secure SDLC comme cadre de contr\u00f4le<\/h2>\n

Le Secure Software Development Lifecycle (Secure SDLC) est souvent pr\u00e9sent\u00e9 comme une m\u00e9thodologie de d\u00e9veloppement \u2014 une s\u00e9quence de pratiques que les \u00e9quipes d’ing\u00e9nierie suivent pour construire des logiciels plus s\u00fbrs. Pour les auditeurs et les responsables conformit\u00e9, cependant, 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 devraient avoir lieu, des preuves sp\u00e9cifiques devraient \u00eatre g\u00e9n\u00e9r\u00e9es et des r\u00e9sultats sp\u00e9cifiques devraient \u00eatre v\u00e9rifiables. Lorsqu’une organisation pr\u00e9tend exploiter un Secure SDLC, les auditeurs doivent aller au-del\u00e0 de la documentation des 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 ressemblent les bonnes pratiques et ce qui devrait susciter des inqui\u00e9tudes.<\/p>\n

Phase PLAN<\/h2>\n

Ce qui devrait se passer<\/h3>\n

Les consid\u00e9rations de s\u00e9curit\u00e9 sont int\u00e9gr\u00e9es dans la planification du projet avant tout d\u00e9but de 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 parall\u00e8lement aux exigences fonctionnelles et la classification de l’application selon le cadre de classification des risques de l’organisation.<\/p>\n

Preuves \u00e0 demander<\/h3>\n
    \n
  • Documentation de mod\u00e9lisation des menaces (diagrammes de flux de donn\u00e9es, identification des menaces, d\u00e9cisions d’att\u00e9nuation)<\/li>\n
  • Exigences de s\u00e9curit\u00e9 document\u00e9es dans le backlog du projet ou le r\u00e9f\u00e9rentiel d’exigences<\/li>\n
  • Enregistrement de classification des risques de l’application avec approbation<\/li>\n
  • Traces de l’implication de la s\u00e9curit\u00e9 dans les sessions de planification<\/li>\n<\/ul>\n

    Ce \u00e0 quoi ressemblent les bonnes pratiques<\/h3>\n
      \n
    • Les mod\u00e8les de menaces sont cr\u00e9\u00e9s pour toutes les applications de Tier 1 et Tier 2 et mis \u00e0 jour lors de changements d’architecture<\/li>\n
    • Les exigences de s\u00e9curit\u00e9 sont tra\u00e7ables \u2014 chaque menace identifi\u00e9e dans le mod\u00e8le a une exigence correspondante ou un risque accept\u00e9<\/li>\n
    • La classification d\u00e9termine les exigences de contr\u00f4le en aval (fr\u00e9quence des tests, workflows d’approbation)<\/li>\n
    • Le personnel de s\u00e9curit\u00e9 participe aux activit\u00e9s de planification, attest\u00e9 par les comptes rendus de r\u00e9union<\/li>\n<\/ul>\n

      Ce \u00e0 quoi ressemblent les mauvaises pratiques<\/h3>\n
        \n
      • Aucun mod\u00e8le de menaces n’existe, ou ils ont \u00e9t\u00e9 cr\u00e9\u00e9s une fois et jamais mis \u00e0 jour<\/li>\n
      • Les exigences de s\u00e9curit\u00e9 sont g\u00e9n\u00e9riques (\u00ab l’application doit \u00eatre s\u00e9curis\u00e9e \u00bb) plut\u00f4t que sp\u00e9cifiques et testables<\/li>\n
      • La classification de l’application est manquante ou a \u00e9t\u00e9 effectu\u00e9e sans l’apport de la s\u00e9curit\u00e9 ou de la conformit\u00e9<\/li>\n
      • La s\u00e9curit\u00e9 n’est impliqu\u00e9e qu’au moment des tests ou du d\u00e9ploiement<\/li>\n<\/ul>\n

        Phase CODE<\/h2>\n

        Ce qui devrait se passer<\/h3>\n

        Les d\u00e9veloppeurs suivent des standards de codage s\u00e9curis\u00e9 document\u00e9s. Les modifications de code sont revues pour les probl\u00e8mes de s\u00e9curit\u00e9 \u2014 soit par revue par les pairs avec des r\u00e9viseurs sensibilis\u00e9s \u00e0 la s\u00e9curit\u00e9, soit par des tests automatis\u00e9s SAST (Static Application Security Testing). Le scanning de secrets emp\u00eache les identifiants, cl\u00e9s API et tokens d’\u00eatre commit\u00e9s dans les d\u00e9p\u00f4ts.<\/p>\n

        Preuves \u00e0 demander<\/h3>\n
          \n
        • Document de standards de codage s\u00e9curis\u00e9, approuv\u00e9 et versionn\u00e9<\/li>\n
        • Enregistrements de revue de code montrant des commentaires li\u00e9s \u00e0 la s\u00e9curit\u00e9 et leurs r\u00e9solutions<\/li>\n
        • R\u00e9sultats de scan SAST int\u00e9gr\u00e9s dans le workflow de d\u00e9veloppement<\/li>\n
        • Configuration du scanning de secrets et enregistrements d’alertes<\/li>\n
        • Registres de formation des d\u00e9veloppeurs aux pratiques de codage s\u00e9curis\u00e9<\/li>\n<\/ul>\n

          Ce \u00e0 quoi ressemblent les bonnes pratiques<\/h3>\n
            \n
          • SAST s’ex\u00e9cute automatiquement sur chaque pull request ou commit, avec des r\u00e9sultats visibles pour les d\u00e9veloppeurs<\/li>\n
          • Les enregistrements de revue de code montrent des constats de s\u00e9curit\u00e9 identifi\u00e9s et trait\u00e9s \u2014 pas seulement une revue fonctionnelle<\/li>\n
          • Le scanning de secrets bloque les commits contenant des identifiants, avec un processus document\u00e9 pour la rotation de tout secret expos\u00e9<\/li>\n
          • Les d\u00e9veloppeurs re\u00e7oivent une formation annuelle (minimum) de codage s\u00e9curis\u00e9 pertinente pour leur stack technologique<\/li>\n<\/ul>\n

            Ce \u00e0 quoi ressemblent les mauvaises pratiques<\/h3>\n
              \n
            • SAST est ex\u00e9cut\u00e9 manuellement ou uniquement avant les releases, ce qui signifie que les vuln\u00e9rabilit\u00e9s s’accumulent<\/li>\n
            • Les revues de code existent mais n’incluent jamais de retour li\u00e9 \u00e0 la s\u00e9curit\u00e9<\/li>\n
            • Aucun scanning de secrets n’est en place, ou les alertes sont ignor\u00e9es<\/li>\n
            • Les standards de codage s\u00e9curis\u00e9 sont obsol\u00e8tes ou non align\u00e9s avec les technologies utilis\u00e9es<\/li>\n<\/ul>\n

              Phase BUILD<\/h2>\n

              Ce qui devrait se passer<\/h3>\n

              Le processus de build inclut une analyse de composition logicielle (SCA) pour identifier les vuln\u00e9rabilit\u00e9s dans les d\u00e9pendances tierces et open-source. Un SBOM (Software Bill of Materials) est g\u00e9n\u00e9r\u00e9 pour chaque build afin de maintenir un inventaire de tous les composants. Les artefacts de build sont sign\u00e9s pour garantir l’int\u00e9grit\u00e9 et pr\u00e9venir la falsification.<\/p>\n

              Preuves \u00e0 demander<\/h3>\n
                \n
              • R\u00e9sultats de scan SCA pour les builds r\u00e9cents, montrant les vuln\u00e9rabilit\u00e9s identifi\u00e9es et leur traitement<\/li>\n
              • Enregistrements SBOM pour les releases en production<\/li>\n
              • Configuration de signature des artefacts et enregistrements de v\u00e9rification<\/li>\n
              • Politique pour les seuils de vuln\u00e9rabilit\u00e9s acceptables dans les d\u00e9pendances<\/li>\n<\/ul>\n

                Ce \u00e0 quoi ressemblent les bonnes pratiques<\/h3>\n
                  \n
                • SCA s’ex\u00e9cute sur chaque build avec des politiques d\u00e9finies pour bloquer les builds contenant des vuln\u00e9rabilit\u00e9s critiques ou de haute s\u00e9v\u00e9rit\u00e9<\/li>\n
                • Les SBOM sont g\u00e9n\u00e9r\u00e9s automatiquement et stock\u00e9s avec les enregistrements de release<\/li>\n
                • La signature des artefacts est impos\u00e9e \u2014 les artefacts non sign\u00e9s ne peuvent pas \u00eatre d\u00e9ploy\u00e9s en production<\/li>\n
                • Un processus existe pour le patching d’urgence des vuln\u00e9rabilit\u00e9s critiques de d\u00e9pendances<\/li>\n<\/ul>\n

                  Ce \u00e0 quoi ressemblent les mauvaises pratiques<\/h3>\n
                    \n
                  • SCA n’est pas int\u00e9gr\u00e9 dans le processus de build ou ne s’ex\u00e9cute que p\u00e9riodiquement<\/li>\n
                  • Pas de g\u00e9n\u00e9ration de SBOM \u2014 l’organisation ne peut pas identifier quels composants sont en production<\/li>\n
                  • Pas de signature d’artefacts \u2014 il n’y a aucun moyen de v\u00e9rifier que les artefacts d\u00e9ploy\u00e9s correspondent aux builds approuv\u00e9s<\/li>\n
                  • Des vuln\u00e9rabilit\u00e9s critiques connues dans les d\u00e9pendances sont pr\u00e9sentes en production sans acceptation document\u00e9e<\/li>\n<\/ul>\n

                    Phase TEST<\/h2>\n

                    Ce qui devrait se passer<\/h3>\n

                    Des tests DAST (Dynamic Application Security Testing) sont effectu\u00e9s sur les applications en cours d’ex\u00e9cution pour identifier les vuln\u00e9rabilit\u00e9s que l’analyse statique ne peut pas d\u00e9tecter (failles d’authentification, probl\u00e8mes de configuration, vuln\u00e9rabilit\u00e9s d’injection en runtime). Les tests de p\u00e9n\u00e9tration par du personnel qualifi\u00e9 apportent une perspective adversariale. Les environnements de test sont isol\u00e9s de la production pour pr\u00e9venir les fuites de donn\u00e9es.<\/p>\n

                    Preuves \u00e0 demander<\/h3>\n
                      \n
                    • R\u00e9sultats de scan DAST et enregistrements de rem\u00e9diation<\/li>\n
                    • Rapports de tests de p\u00e9n\u00e9tration avec p\u00e9rim\u00e8tre, m\u00e9thodologie, constats et \u00e9tat de rem\u00e9diation<\/li>\n
                    • Preuves d’isolation des environnements (diagrammes r\u00e9seau, contr\u00f4les d’acc\u00e8s)<\/li>\n
                    • Enregistrements montrant que la fr\u00e9quence des tests est align\u00e9e avec le niveau de risque de l’application<\/li>\n<\/ul>\n

                      Ce \u00e0 quoi ressemblent les bonnes pratiques<\/h3>\n
                        \n
                      • DAST est automatis\u00e9 et s’ex\u00e9cute \u00e0 la fr\u00e9quence sp\u00e9cifi\u00e9e par la classification de risque de l’application<\/li>\n
                      • Les tests de p\u00e9n\u00e9tration sont men\u00e9s par des testeurs ind\u00e9pendants qualifi\u00e9s (internes ou externes) avec un p\u00e9rim\u00e8tre d\u00e9fini<\/li>\n
                      • Les environnements de test ne contiennent pas de donn\u00e9es de production, ou les donn\u00e9es de production sont correctement masqu\u00e9es<\/li>\n
                      • Les constats des tests sont suivis jusqu’\u00e0 la rem\u00e9diation v\u00e9rifi\u00e9e<\/li>\n<\/ul>\n

                        Ce \u00e0 quoi ressemblent les mauvaises pratiques<\/h3>\n
                          \n
                        • DAST n’est pas effectu\u00e9, ou les r\u00e9sultats sont ignor\u00e9s<\/li>\n
                        • Les tests de p\u00e9n\u00e9tration sont effectu\u00e9s par la m\u00eame \u00e9quipe qui a construit l’application, sans ind\u00e9pendance<\/li>\n
                        • Les environnements de test contiennent des donn\u00e9es de production non masqu\u00e9es<\/li>\n
                        • Les constats de tests restent ouverts ind\u00e9finiment sans escalade<\/li>\n<\/ul>\n

                          Phase RELEASE<\/h2>\n

                          Ce qui devrait se passer<\/h3>\n

                          Les releases sont soumises \u00e0 des workflows d’approbation qui v\u00e9rifient que toutes les activit\u00e9s de s\u00e9curit\u00e9 requises ont \u00e9t\u00e9 compl\u00e9t\u00e9es. Les portes de politique dans le pipeline de livraison imposent que les exigences de s\u00e9curit\u00e9 soient satisfaites avant que le code puisse passer en production. Les d\u00e9cisions de release sont document\u00e9es dans le cadre de la gestion des changements.<\/p>\n

                          Preuves \u00e0 demander<\/h3>\n
                            \n
                          • Enregistrements d’approbation de release montrant la validation s\u00e9curit\u00e9 lorsque requise<\/li>\n
                          • R\u00e9sultats des portes de politique du pipeline de livraison (enregistrements pass\/fail avec horodatages)<\/li>\n
                          • Enregistrements de gestion des changements liant les releases aux r\u00e9sultats des tests de s\u00e9curit\u00e9<\/li>\n
                          • Enregistrements d’exception pour toute release ayant contourn\u00e9 les portes de politique<\/li>\n<\/ul>\n

                            Ce \u00e0 quoi ressemblent les bonnes pratiques<\/h3>\n
                              \n
                            • Les portes de politique sont automatis\u00e9es et impos\u00e9es \u2014 le pipeline emp\u00eache la release si les crit\u00e8res de s\u00e9curit\u00e9 ne sont pas satisfaits<\/li>\n
                            • La validation s\u00e9curit\u00e9 est requise pour les applications de Tier 1 et Tier 2, avec une approbation document\u00e9e<\/li>\n
                            • Les contournements de portes n\u00e9cessitent une approbation formelle d’exception et sont suivis<\/li>\n
                            • Les enregistrements de release sont li\u00e9s \u00e0 des r\u00e9sultats de scan et des r\u00e9sultats de tests sp\u00e9cifiques<\/li>\n<\/ul>\n

                              Ce \u00e0 quoi ressemblent les mauvaises pratiques<\/h3>\n