{"id":1371,"date":"2026-03-25T17:02:21","date_gmt":"2026-03-25T16:02:21","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/pci-dss-v4-0-software-delivery-requirements-requirement-6-deep-dive-2\/"},"modified":"2026-03-26T00:20:15","modified_gmt":"2026-03-25T23:20:15","slug":"pci-dss-v4-0-software-delivery-requirements-requirement-6-deep-dive","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/pci-dss-v4-0-software-delivery-requirements-requirement-6-deep-dive\/","title":{"rendered":"PCI DSS v4.0 \u2014 Exigences de livraison logicielle (Analyse approfondie de l’exigence 6)"},"content":{"rendered":"

Aper\u00e7u : Exigence 6 de PCI DSS v4.0<\/h2>\n

L’exigence 6 de PCI DSS v4.0 \u2014 D\u00e9velopper et maintenir des syst\u00e8mes et logiciels s\u00e9curis\u00e9s<\/em> \u2014 est l’exigence la plus directement pertinente pour les organisations utilisant des pipelines CI\/CD pour livrer des logiciels qui traitent, stockent ou transmettent des donn\u00e9es de titulaires de cartes. Cette exigence \u00e9tablit des attentes pour les pratiques de d\u00e9veloppement s\u00e9curis\u00e9, la gestion des vuln\u00e9rabilit\u00e9s, le contr\u00f4le des changements et les tests de s\u00e9curit\u00e9 applicatifs.<\/p>\n

Pour les responsables conformit\u00e9 et les auditeurs, comprendre comment chaque sous-exigence se rapporte aux contr\u00f4les CI\/CD est essentiel tant pour impl\u00e9menter des pipelines conformes que pour v\u00e9rifier la conformit\u00e9 lors des \u00e9valuations.<\/p>\n

Sous-exigence 6.1 : \u00c9tablir et maintenir des processus de d\u00e9veloppement s\u00e9curis\u00e9<\/h2>\n

L’exigence 6.1 impose que les organisations \u00e9tablissent, documentent et maintiennent des processus d’identification des vuln\u00e9rabilit\u00e9s de s\u00e9curit\u00e9 et de d\u00e9veloppement de syst\u00e8mes et logiciels s\u00e9curis\u00e9s.<\/p>\n

Pertinence CI\/CD<\/h3>\n
    \n
  • Cycle de d\u00e9veloppement s\u00e9curis\u00e9 (SDLC) document\u00e9 :<\/strong> Le SDLC doit explicitement aborder comment les pipelines CI\/CD appliquent les pratiques de d\u00e9veloppement s\u00e9curis\u00e9<\/li>\n
  • Revue annuelle des processus de d\u00e9veloppement :<\/strong> Les contr\u00f4les et configurations de s\u00e9curit\u00e9 du pipeline doivent \u00eatre r\u00e9vis\u00e9s au moins annuellement et mis \u00e0 jour lorsque l’environnement change<\/li>\n
  • Formation du personnel de d\u00e9veloppement :<\/strong> Les \u00e9quipes doivent \u00eatre form\u00e9es aux pratiques de codage s\u00e9curis\u00e9 et \u00e0 l’utilisation efficace des outils de s\u00e9curit\u00e9 du pipeline<\/li>\n<\/ul>\n

    Preuves pour l’\u00e9valuation<\/h3>\n
      \n
    • Politique SDLC document\u00e9e r\u00e9f\u00e9ren\u00e7ant les contr\u00f4les de s\u00e9curit\u00e9 CI\/CD<\/li>\n
    • Enregistrements de revue annuelle avec changements identifi\u00e9s et approbations<\/li>\n
    • Enregistrements de compl\u00e9tion de formation pour le personnel de d\u00e9veloppement<\/li>\n<\/ul>\n

      Sous-exigence 6.2 : D\u00e9velopper des logiciels de mani\u00e8re s\u00e9curis\u00e9e<\/h2>\n

      L’exigence 6.2 traite des pratiques \u00e0 suivre pendant le d\u00e9veloppement logiciel, incluant le codage s\u00e9curis\u00e9, la revue de code et les tests de s\u00e9curit\u00e9.<\/p>\n

      Pertinence CI\/CD<\/h3>\n
        \n
      • Standards de codage s\u00e9curis\u00e9 :<\/strong> Application par le pipeline des standards de codage via le linting automatis\u00e9 et l’analyse statique<\/li>\n
      • Revue de code avant publication :<\/strong> Revue par les pairs obligatoire appliqu\u00e9e via la protection de branche et les exigences de merge request<\/li>\n
      • Int\u00e9gration des tests de s\u00e9curit\u00e9 :<\/strong> SAST, SCA et d\u00e9tection de secrets int\u00e9gr\u00e9s dans le pipeline avec des crit\u00e8res de r\u00e9ussite\/\u00e9chec d\u00e9finis<\/li>\n
      • S\u00e9paration des environnements de d\u00e9veloppement, test et production :<\/strong> L’architecture du pipeline doit appliquer la s\u00e9gr\u00e9gation des environnements<\/li>\n<\/ul>\n

        Preuves pour l’\u00e9valuation<\/h3>\n
          \n
        • Configuration du pipeline montrant les \u00e9tapes d’analyse de s\u00e9curit\u00e9<\/li>\n
        • R\u00e8gles de protection de branche exigeant la revue de code<\/li>\n
        • R\u00e9sultats d’analyse de s\u00e9curit\u00e9 et journaux d’application des portes<\/li>\n
        • Documentation d’architecture des environnements d\u00e9montrant la s\u00e9gr\u00e9gation<\/li>\n<\/ul>\n

          Sous-exigence 6.3 : Identifier et g\u00e9rer les vuln\u00e9rabilit\u00e9s de s\u00e9curit\u00e9<\/h2>\n

          L’exigence 6.3 se concentre sur l’identification des vuln\u00e9rabilit\u00e9s, le classement des risques et la rem\u00e9diation rapide sur tous les composants syst\u00e8me.<\/p>\n

          Pertinence CI\/CD<\/h3>\n
            \n
          • Analyse des vuln\u00e9rabilit\u00e9s du code personnalis\u00e9 :<\/strong> L’analyse automatis\u00e9e des vuln\u00e9rabilit\u00e9s doit faire partie du processus de build<\/li>\n
          • Gestion des vuln\u00e9rabilit\u00e9s des composants tiers :<\/strong> L’analyse des d\u00e9pendances doit identifier les vuln\u00e9rabilit\u00e9s connues dans les biblioth\u00e8ques et frameworks consomm\u00e9s via le pipeline<\/li>\n
          • Rem\u00e9diation class\u00e9e par risque :<\/strong> Les portes du pipeline doivent appliquer les d\u00e9lais de rem\u00e9diation bas\u00e9s sur la gravit\u00e9 des vuln\u00e9rabilit\u00e9s (les vuln\u00e9rabilit\u00e9s critiques\/\u00e9lev\u00e9es bloquent le d\u00e9ploiement)<\/li>\n
          • Gestion des correctifs :<\/strong> L’infrastructure du pipeline elle-m\u00eame (outils de build, runners, images de conteneurs) doit \u00eatre corrig\u00e9e et mise \u00e0 jour<\/li>\n<\/ul>\n

            Changements sp\u00e9cifiques v4.0<\/h3>\n

            PCI DSS v4.0 introduit des exigences plus prescriptives concernant les d\u00e9lais de gestion des vuln\u00e9rabilit\u00e9s. Les vuln\u00e9rabilit\u00e9s critiques et de haute gravit\u00e9 doivent \u00eatre trait\u00e9es rapidement, et les organisations doivent d\u00e9finir et suivre leurs propres d\u00e9lais de rem\u00e9diation bas\u00e9s sur le classement des risques.<\/p>\n

            Sous-exigence 6.4 : Prot\u00e9ger les applications web expos\u00e9es au public<\/h2>\n

            L’exigence 6.4 exige la protection des applications web expos\u00e9es au public contre les attaques connues, soit par des \u00e9valuations de vuln\u00e9rabilit\u00e9 manuelles\/automatis\u00e9es, soit par des pare-feux d’applications web.<\/p>\n

            Pertinence CI\/CD<\/h3>\n
              \n
            • Int\u00e9gration DAST :<\/strong> Les tests dynamiques de s\u00e9curit\u00e9 applicative peuvent \u00eatre int\u00e9gr\u00e9s dans les pipelines de d\u00e9ploiement pour les environnements de staging ou de pr\u00e9-production<\/li>\n
            • Automatisation du d\u00e9ploiement WAF :<\/strong> D\u00e9ploiement et configuration des r\u00e8gles WAF g\u00e9r\u00e9s par le pipeline<\/li>\n
            • Planification des \u00e9valuations de vuln\u00e9rabilit\u00e9 :<\/strong> \u00c9valuations automatis\u00e9es des vuln\u00e9rabilit\u00e9s d\u00e9clench\u00e9es par les d\u00e9ploiements ou selon des calendriers d\u00e9finis<\/li>\n<\/ul>\n

              Changements sp\u00e9cifiques v4.0<\/h3>\n

              PCI DSS v4.0 (sp\u00e9cifiquement 6.4.2) exige des solutions techniques automatis\u00e9es pour les applications web expos\u00e9es au public qui d\u00e9tectent et pr\u00e9viennent continuellement les attaques bas\u00e9es sur le web. Il s’agit d’une exigence \u00e0 date future devenue obligatoire apr\u00e8s le 31 mars 2025.<\/p>\n

              Sous-exigence 6.5 : G\u00e9rer les changements des composants syst\u00e8me<\/h2>\n

              L’exigence 6.5 \u00e9tablit des exigences de gestion des changements qui r\u00e9gissent directement le fonctionnement des pipelines CI\/CD.<\/p>\n

              Pertinence CI\/CD<\/h3>\n
                \n
              • Proc\u00e9dures document\u00e9es de contr\u00f4le des changements :<\/strong> Le pipeline lui-m\u00eame doit \u00eatre r\u00e9gi par une proc\u00e9dure document\u00e9e de contr\u00f4le des changements<\/li>\n
              • Analyse d’impact :<\/strong> Les changements doivent inclure une documentation d’impact, y compris l’impact s\u00e9curit\u00e9<\/li>\n
              • Approbation autoris\u00e9e :<\/strong> Tous les changements aux syst\u00e8mes de production doivent \u00eatre formellement approuv\u00e9s par du personnel autoris\u00e9<\/li>\n
              • Exigences de test :<\/strong> Les changements doivent \u00eatre test\u00e9s avant le d\u00e9ploiement en production, avec les tests v\u00e9rifi\u00e9s via les portes du pipeline<\/li>\n
              • Proc\u00e9dures de rollback :<\/strong> Proc\u00e9dures document\u00e9es pour annuler les changements causant des probl\u00e8mes<\/li>\n
              • S\u00e9gr\u00e9gation du d\u00e9veloppement, du test et de la production :<\/strong> L’architecture du pipeline doit emp\u00eacher les donn\u00e9es de test ou les configurations de d\u00e9veloppement d’atteindre la production<\/li>\n<\/ul>\n

                Cartographie compl\u00e8te : Sous-exigence vers contr\u00f4le CI\/CD<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
                Sous-exigence PCI DSS<\/th>\nContr\u00f4le CI\/CD<\/th>\nPreuves<\/th>\nM\u00e9thode de v\u00e9rification QSA<\/th>\n<\/tr>\n<\/thead>\n
                6.1.1 \u2014 R\u00f4les de s\u00e9curit\u00e9 d\u00e9finis<\/td>\nR\u00f4les RBAC pour l’acc\u00e8s et les op\u00e9rations du pipeline<\/td>\nD\u00e9finitions de r\u00f4les, configuration RBAC<\/td>\nRevoir la documentation des r\u00f4les ; v\u00e9rifier la correspondance de la configuration<\/td>\n<\/tr>\n
                6.1.2 \u2014 Revue annuelle des processus<\/td>\nProcessus de revue annuelle de s\u00e9curit\u00e9 du pipeline<\/td>\nEnregistrements de revue, journal des changements, enregistrements d’approbation<\/td>\nExaminer la documentation de revue ; confirmer que le p\u00e9rim\u00e8tre inclut le CI\/CD<\/td>\n<\/tr>\n
                6.2.1 \u2014 Formation au codage s\u00e9curis\u00e9<\/td>\nFormation des d\u00e9veloppeurs aux outils de s\u00e9curit\u00e9 du pipeline et au codage s\u00e9curis\u00e9<\/td>\nEnregistrements de formation, certificats de compl\u00e9tion<\/td>\n\u00c9chantillonner les enregistrements de formation ; interviewer les d\u00e9veloppeurs<\/td>\n<\/tr>\n
                6.2.2 \u2014 Revue de code avant production<\/td>\nRevue par les pairs obligatoire via la protection de branche<\/td>\nConfiguration de protection de branche, journaux de merge request<\/td>\nV\u00e9rifier la configuration ; \u00e9chantillonner les merge requests pour l’attestation du r\u00e9viseur<\/td>\n<\/tr>\n
                6.2.3 \u2014 Tests de s\u00e9curit\u00e9 dans le SDLC<\/td>\nSAST, SCA int\u00e9gr\u00e9s dans le pipeline avec portes bloquantes<\/td>\nConfiguration du pipeline, r\u00e9sultats d’analyse, journaux des portes<\/td>\nRevoir la d\u00e9finition du pipeline ; \u00e9chantillonner les journaux de build montrant l’ex\u00e9cution des analyses<\/td>\n<\/tr>\n
                6.2.4 \u2014 Techniques de codage s\u00e9curis\u00e9<\/td>\nApplication automatis\u00e9e des standards de codage via linters et r\u00e8gles SAST<\/td>\nConfiguration des outils, jeux de r\u00e8gles, journaux d’application<\/td>\nRevoir la configuration des r\u00e8gles ; v\u00e9rifier l’application sur des builds \u00e9chantillonn\u00e9s<\/td>\n<\/tr>\n
                6.3.1 \u2014 Identification des vuln\u00e9rabilit\u00e9s<\/td>\nAnalyse automatis\u00e9e des vuln\u00e9rabilit\u00e9s dans le pipeline de build<\/td>\nConfiguration d’analyse, rapports de vuln\u00e9rabilit\u00e9s<\/td>\nV\u00e9rifier que l’analyse s’ex\u00e9cute \u00e0 chaque build ; revoir les rapports \u00e9chantillonn\u00e9s<\/td>\n<\/tr>\n
                6.3.2 \u2014 Inventaire logiciel maintenu<\/td>\nG\u00e9n\u00e9ration SBOM via le pipeline<\/td>\nArtefacts SBOM, inventaires des d\u00e9pendances<\/td>\nV\u00e9rifier la g\u00e9n\u00e9ration SBOM ; comparer avec les composants d\u00e9ploy\u00e9s<\/td>\n<\/tr>\n
                6.3.3 \u2014 Correctifs et mises \u00e0 jour appliqu\u00e9s rapidement<\/td>\nD\u00e9tection automatis\u00e9e des mises \u00e0 jour de d\u00e9pendances, suivi des SLA de rem\u00e9diation<\/td>\nRapports de vieillissement des vuln\u00e9rabilit\u00e9s, d\u00e9lais de rem\u00e9diation<\/td>\n\u00c9chantillonner les vuln\u00e9rabilit\u00e9s ; v\u00e9rifier la rem\u00e9diation dans les SLA d\u00e9finis<\/td>\n<\/tr>\n
                6.4.1 \u2014 D\u00e9tection des vuln\u00e9rabilit\u00e9s des applications web<\/td>\nInt\u00e9gration DAST dans le pipeline de d\u00e9ploiement<\/td>\nConfiguration DAST, r\u00e9sultats d’analyse, enregistrements de rem\u00e9diation<\/td>\nV\u00e9rifier l’ex\u00e9cution DAST ; revoir les conclusions et la rem\u00e9diation<\/td>\n<\/tr>\n
                6.5.1 \u2014 Proc\u00e9dures de contr\u00f4le des changements suivies<\/td>\nGestion des changements appliqu\u00e9e par le pipeline avec approbation obligatoire<\/td>\nJournaux de d\u00e9ploiement avec enregistrements d’approbation<\/td>\n\u00c9chantillonner les d\u00e9ploiements ; v\u00e9rifier l’approbation avant l’ex\u00e9cution<\/td>\n<\/tr>\n
                6.5.2 \u2014 Documentation des changements compl\u00e8te<\/td>\n\u00c9l\u00e9ments de travail li\u00e9s, descriptions d’impact, preuves de test dans les enregistrements de d\u00e9ploiement<\/td>\nEnregistrements de changement avec documentation compl\u00e8te<\/td>\n\u00c9chantillonner les changements ; v\u00e9rifier la compl\u00e9tude de la documentation<\/td>\n<\/tr>\n
                6.5.3 \u2014 Environnement de production s\u00e9gr\u00e9g\u00e9<\/td>\nIsolation des environnements du pipeline, identifiants s\u00e9par\u00e9s, segmentation r\u00e9seau<\/td>\nSch\u00e9mas d’architecture, preuves de configuration<\/td>\nRevoir l’architecture ; v\u00e9rifier les contr\u00f4les d’isolation<\/td>\n<\/tr>\n
                6.5.4 \u2014 S\u00e9paration des t\u00e2ches<\/td>\nApplication par le pipeline emp\u00eachant l’auto-approbation et l’auto-d\u00e9ploiement<\/td>\nConfiguration SoD, rapports de validation<\/td>\nV\u00e9rifier la configuration ; \u00e9chantillonner les d\u00e9ploiements pour la conformit\u00e9 SoD<\/td>\n<\/tr>\n
                6.5.5 \u2014 PAN r\u00e9els non utilis\u00e9s en test<\/td>\nMasquage des donn\u00e9es par le pipeline, contr\u00f4les de donn\u00e9es d’environnement<\/td>\nProc\u00e9dures de gestion des donn\u00e9es, gestion des donn\u00e9es de test<\/td>\nRevoir les proc\u00e9dures de donn\u00e9es de test ; v\u00e9rifier l’absence de donn\u00e9es r\u00e9elles dans les environnements inf\u00e9rieurs<\/td>\n<\/tr>\n
                6.5.6 \u2014 Donn\u00e9es de test supprim\u00e9es avant la production<\/td>\n\u00c9tapes de nettoyage du pipeline, v\u00e9rification du d\u00e9ploiement en production<\/td>\nProc\u00e9dures de d\u00e9ploiement, journaux de v\u00e9rification de nettoyage<\/td>\nRevoir le processus de d\u00e9ploiement ; v\u00e9rifier les \u00e9tapes de nettoyage<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                Nouvelles exigences v4.0 affectant le CI\/CD<\/h2>\n

                Approche personnalis\u00e9e<\/h3>\n

                PCI DSS v4.0 introduit l’\u00ab approche personnalis\u00e9e \u00bb comme alternative \u00e0 l’\u00ab approche d\u00e9finie \u00bb traditionnelle. Les organisations peuvent r\u00e9pondre \u00e0 l’objectif de s\u00e9curit\u00e9 d’une exigence par des contr\u00f4les alternatifs, \u00e0 condition de d\u00e9montrer que le contr\u00f4le atteint l’objectif d\u00e9clar\u00e9. Pour les environnements CI\/CD, cela offre la flexibilit\u00e9 d’impl\u00e9menter des contr\u00f4les natifs au pipeline plut\u00f4t que de r\u00e9troconcevoir des contr\u00f4les traditionnels.<\/p>\n

                Ce que cela signifie pour les responsables conformit\u00e9 :<\/strong> Si votre pipeline impl\u00e9mente des contr\u00f4les diff\u00e9remment de l’exigence prescriptive mais atteint le m\u00eame objectif de s\u00e9curit\u00e9, l’approche personnalis\u00e9e peut \u00eatre appropri\u00e9e. Cependant, cela n\u00e9cessite une analyse cibl\u00e9e des risques pour chaque contr\u00f4le personnalis\u00e9 et des preuves plus rigoureuses d’efficacit\u00e9.<\/p>\n

                Analyse cibl\u00e9e des risques<\/h3>\n

                La v4.0 exige des analyses cibl\u00e9es des risques document\u00e9es pour des exigences sp\u00e9cifiques o\u00f9 l’organisation d\u00e9termine la fr\u00e9quence ou le p\u00e9rim\u00e8tre d’une activit\u00e9 de contr\u00f4le. Pour les pipelines CI\/CD, cela inclut :<\/p>\n