{"id":1480,"date":"2026-03-25T16:52:28","date_gmt":"2026-03-25T15:52:28","guid":{"rendered":"https:\/\/regulated-devsecops.com\/pci-dss\/"},"modified":"2026-03-26T07:08:17","modified_gmt":"2026-03-26T06:08:17","slug":"pci-dss","status":"publish","type":"page","link":"https:\/\/regulated-devsecops.com\/fr\/compliance\/pci-dss\/","title":{"rendered":"PCI DSS et s\u00e9curit\u00e9 CI\/CD"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">PCI DSS v4.0 : s\u00e9curiser la cha\u00eene de livraison logicielle pour les environnements de donn\u00e9es de titulaires de carte<\/h2>\n\n\n\n<p>Le Payment Card Industry Data Security Standard (PCI DSS) v4.0 r\u00e9git toute organisation qui traite, stocke ou transmet des donn\u00e9es de titulaires de carte. Avec la version 4.0 d\u00e9sormais pleinement en vigueur \u2014 y compris les exigences \u00e0 date future devenues obligatoires en mars 2025 \u2014 la norme met un accent consid\u00e9rablement plus important sur la s\u00e9curisation du cycle de d\u00e9veloppement et de d\u00e9ploiement des logiciels. Pour les organisations livrant des applications vers l&rsquo;environnement de donn\u00e9es de titulaires de carte (CDE) via des pipelines CI\/CD, le pipeline lui-m\u00eame devient un composant critique dans le p\u00e9rim\u00e8tre d&rsquo;\u00e9valuation.<\/p>\n\n\n\n<p>Cette page hub fournit des conseils complets sur l&rsquo;alignement des contr\u00f4les de s\u00e9curit\u00e9 CI\/CD avec les exigences PCI DSS v4.0, la compr\u00e9hension des implications de p\u00e9rim\u00e8tre, la pr\u00e9paration aux examens du Qualified Security Assessor (QSA) et le traitement des constats d&rsquo;\u00e9valuation les plus courants dans les environnements de livraison logicielle.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Aper\u00e7u PCI DSS v4.0<\/h2>\n\n\n\n<p>PCI DSS v4.0 est structur\u00e9 autour de 12 exigences principales, organis\u00e9es en six objectifs de contr\u00f4le. La norme s&rsquo;applique \u00e0 toutes les entit\u00e9s impliqu\u00e9es dans le traitement des cartes de paiement \u2014 commer\u00e7ants, prestataires de services, acqu\u00e9reurs et \u00e9metteurs \u2014 le niveau d&rsquo;\u00e9valuation \u00e9tant d\u00e9termin\u00e9 par le volume de transactions et le type d&rsquo;entit\u00e9.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">M\u00e9thodes d&rsquo;\u00e9valuation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Self-Assessment Questionnaire (SAQ) :<\/strong> Un outil d&rsquo;auto-validation pour les petits commer\u00e7ants et prestataires de services r\u00e9pondant \u00e0 des crit\u00e8res d&rsquo;\u00e9ligibilit\u00e9 sp\u00e9cifiques. Plusieurs types de SAQ existent selon la mani\u00e8re dont les donn\u00e9es de titulaires de carte sont trait\u00e9es.<\/li>\n\n\n\n<li><strong>Report on Compliance (ROC) :<\/strong> Une \u00e9valuation d\u00e9taill\u00e9e r\u00e9alis\u00e9e par un QSA, requise pour les commer\u00e7ants et prestataires de services de niveau 1. Le ROC documente les constats de l&rsquo;\u00e9valuateur par rapport \u00e0 chaque exigence applicable.<\/li>\n\n\n\n<li><strong>Qualified Security Assessor (QSA) :<\/strong> Un \u00e9valuateur ind\u00e9pendant certifi\u00e9 par le PCI Security Standards Council pour \u00e9valuer la conformit\u00e9. Les QSA r\u00e9alisent des \u00e9valuations sur site, examinent les preuves, interrogent le personnel et observent les processus.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">L&rsquo;approche personnalis\u00e9e<\/h3>\n\n\n\n<p>PCI DSS v4.0 introduit une approche personnalis\u00e9e comme alternative \u00e0 l&rsquo;approche d\u00e9finie pour r\u00e9pondre aux exigences. Les organisations peuvent mettre en \u0153uvre des contr\u00f4les diff\u00e9rents de l&rsquo;approche prescriptive d\u00e9finie, \u00e0 condition de pouvoir d\u00e9montrer par une analyse de risque cibl\u00e9e que leurs contr\u00f4les r\u00e9pondent \u00e0 l&rsquo;objectif de chaque exigence. Cela est particuli\u00e8rement pertinent pour les environnements CI\/CD o\u00f9 les pratiques DevSecOps modernes peuvent atteindre le m\u00eame r\u00e9sultat de s\u00e9curit\u00e9 par des moyens diff\u00e9rents de ceux prescrits dans l&rsquo;approche d\u00e9finie.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Quand le CI\/CD est dans le p\u00e9rim\u00e8tre PCI DSS<\/h2>\n\n\n\n<p>Le p\u00e9rim\u00e8tre PCI DSS d\u00e9termine quels syst\u00e8mes, processus et personnes sont soumis \u00e0 l&rsquo;\u00e9valuation. Les pipelines CI\/CD entrent dans le p\u00e9rim\u00e8tre lorsqu&rsquo;ils :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>D\u00e9ploient vers le CDE :<\/strong> Les pipelines qui livrent du code, de la configuration ou des changements d&rsquo;infrastructure vers des syst\u00e8mes qui traitent, stockent ou transmettent des donn\u00e9es de titulaires de carte sont directement dans le p\u00e9rim\u00e8tre.<\/li>\n\n\n\n<li><strong>Manipulent des donn\u00e9es de titulaires de carte :<\/strong> Les pipelines qui traitent des donn\u00e9es de test contenant de vrais PAN, ou qui g\u00e8rent des cl\u00e9s de chiffrement ou des syst\u00e8mes de tokenisation, sont dans le p\u00e9rim\u00e8tre.<\/li>\n\n\n\n<li><strong>Se connectent aux syst\u00e8mes du CDE :<\/strong> Les pipelines qui ont une connectivit\u00e9 r\u00e9seau vers le CDE \u2014 m\u00eame s&rsquo;ils ne manipulent pas directement les donn\u00e9es de titulaires de carte \u2014 peuvent \u00eatre class\u00e9s comme syst\u00e8mes connect\u00e9s ou ayant un impact sur la s\u00e9curit\u00e9.<\/li>\n\n\n\n<li><strong>Affectent la s\u00e9curit\u00e9 du CDE :<\/strong> Les pipelines qui g\u00e8rent les contr\u00f4les de s\u00e9curit\u00e9, les r\u00e8gles de pare-feu, les configurations d&rsquo;acc\u00e8s ou les syst\u00e8mes de surveillance du CDE ont un impact sur la s\u00e9curit\u00e9 et sont donc dans le p\u00e9rim\u00e8tre.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Consid\u00e9rations de segmentation<\/h3>\n\n\n\n<p>Les organisations peuvent r\u00e9duire leur p\u00e9rim\u00e8tre PCI DSS par la segmentation r\u00e9seau \u2014 en isolant le CDE des autres syst\u00e8mes. Pour le CI\/CD, cela signifie envisager si l&rsquo;infrastructure du pipeline peut \u00eatre segment\u00e9e de sorte que seules des \u00e9tapes ou runners sp\u00e9cifiques du pipeline aient acc\u00e8s au CDE. Cependant, les composants du pipeline qui d\u00e9ploient vers ou configurent le CDE resteront dans le p\u00e9rim\u00e8tre ind\u00e9pendamment de la segmentation. La segmentation elle-m\u00eame doit \u00eatre valid\u00e9e dans le cadre de l&rsquo;\u00e9valuation, et les QSA v\u00e9rifieront que les syst\u00e8mes de pipeline en dehors du p\u00e9rim\u00e8tre d\u00e9fini du CDE ne peuvent v\u00e9ritablement pas affecter la s\u00e9curit\u00e9 des donn\u00e9es de titulaires de carte.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Exigences cl\u00e9s pour les environnements CI\/CD<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Exigence 6 \u2014 D\u00e9velopper et maintenir des syst\u00e8mes et logiciels s\u00e9curis\u00e9s<\/h3>\n\n\n\n<p>L&rsquo;exigence 6 est l&rsquo;exigence la plus directement pertinente pour les pipelines CI\/CD et couvre l&rsquo;ensemble du cycle de d\u00e9veloppement et de d\u00e9ploiement logiciel :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>6.2 D\u00e9veloppement s\u00e9curis\u00e9 :<\/strong> Des pratiques de codage s\u00e9curis\u00e9 doivent \u00eatre d\u00e9finies et appliqu\u00e9es. Les d\u00e9veloppeurs doivent \u00eatre form\u00e9s aux techniques de codage s\u00e9curis\u00e9 pertinentes pour les technologies utilis\u00e9es. L&rsquo;organisation doit maintenir des standards de codage s\u00e9curis\u00e9 appliqu\u00e9s via le pipeline \u2014 pas seulement document\u00e9s dans une politique.<\/li>\n\n\n\n<li><strong>6.3 Gestion des vuln\u00e9rabilit\u00e9s :<\/strong> Les vuln\u00e9rabilit\u00e9s dans le code personnalis\u00e9 et les composants tiers doivent \u00eatre identifi\u00e9es, prioris\u00e9es et rem\u00e9di\u00e9es dans des d\u00e9lais d\u00e9finis. Cela inclut le maintien d&rsquo;un inventaire des composants tiers (SBOM), la surveillance des divulgations de vuln\u00e9rabilit\u00e9s et l&rsquo;application rapide des correctifs. Les pipelines CI\/CD doivent int\u00e9grer l&rsquo;analyse des vuln\u00e9rabilit\u00e9s (SCA) et bloquer les d\u00e9ploiements lorsque des vuln\u00e9rabilit\u00e9s critiques sont identifi\u00e9es.<\/li>\n\n\n\n<li><strong>6.4 Applications web expos\u00e9es au public :<\/strong> Les applications expos\u00e9es sur Internet doivent \u00eatre prot\u00e9g\u00e9es contre les attaques courantes. Cela inclut l&rsquo;int\u00e9gration de DAST dans le pipeline de d\u00e9ploiement, la r\u00e9alisation d&rsquo;\u00e9valuations r\u00e9guli\u00e8res des vuln\u00e9rabilit\u00e9s et le d\u00e9ploiement de pare-feu d&rsquo;applications web (WAF) le cas \u00e9ch\u00e9ant.<\/li>\n\n\n\n<li><strong>6.5 Gestion des changements :<\/strong> Tous les changements aux composants syst\u00e8me dans le CDE doivent suivre un processus document\u00e9 de gestion des changements. Cela inclut la revue de code par des personnes autres que l&rsquo;auteur, l&rsquo;approbation document\u00e9e avant le d\u00e9ploiement en production, les tests fonctionnels pour v\u00e9rifier que les changements fonctionnent comme pr\u00e9vu et les proc\u00e9dures de retour en arri\u00e8re. Les pipelines CI\/CD doivent imposer ces exigences via des contr\u00f4les techniques \u2014 protection de branche, revues obligatoires, portes d&rsquo;approbation et tests automatis\u00e9s.<\/li>\n\n\n\n<li><strong>Int\u00e9gration SAST et DAST :<\/strong> Les tests de s\u00e9curit\u00e9 statique doivent \u00eatre effectu\u00e9s sur le code personnalis\u00e9 avant la release, et les tests dynamiques doivent \u00eatre r\u00e9alis\u00e9s sur les applications d\u00e9ploy\u00e9es. L&rsquo;int\u00e9gration dans le pipeline garantit que ces exigences sont respect\u00e9es de mani\u00e8re coh\u00e9rente pour chaque release.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Exigence 7 \u2014 Restreindre l&rsquo;acc\u00e8s aux composants syst\u00e8me et aux donn\u00e9es de titulaires de carte<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Moindre privil\u00e8ge :<\/strong> L&rsquo;acc\u00e8s aux syst\u00e8mes de pipeline qui d\u00e9ploient vers le CDE doit \u00eatre restreint au minimum n\u00e9cessaire pour chaque r\u00f4le. Les comptes de service du pipeline ne doivent avoir que les permissions requises pour leur fonction sp\u00e9cifique.<\/li>\n\n\n\n<li><strong>RBAC :<\/strong> Le contr\u00f4le d&rsquo;acc\u00e8s doit \u00eatre bas\u00e9 sur les r\u00f4les avec des d\u00e9finitions de r\u00f4les document\u00e9es, des octrois d&rsquo;acc\u00e8s approuv\u00e9s et des revues r\u00e9guli\u00e8res pour identifier et rem\u00e9dier les permissions excessives.<\/li>\n\n\n\n<li><strong>Provisionnement et d\u00e9provisionnement d&rsquo;acc\u00e8s :<\/strong> Des processus doivent exister pour accorder l&rsquo;acc\u00e8s au nouveau personnel et supprimer rapidement l&rsquo;acc\u00e8s lors de changements de r\u00f4le ou de d\u00e9part du personnel. Cela s&rsquo;applique aux comptes de plateforme CI\/CD, \u00e0 l&rsquo;acc\u00e8s aux d\u00e9p\u00f4ts et aux identifiants de d\u00e9ploiement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Exigence 8 \u2014 Identifier les utilisateurs et authentifier les acc\u00e8s<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>MFA pour l&rsquo;acc\u00e8s administratif :<\/strong> Tout acc\u00e8s administratif aux syst\u00e8mes de pipeline, y compris la configuration de la plateforme CI\/CD, la gestion des secrets et les contr\u00f4les de d\u00e9ploiement en production, doit n\u00e9cessiter l&rsquo;authentification multifacteur.<\/li>\n\n\n\n<li><strong>Pas de comptes partag\u00e9s ou g\u00e9n\u00e9riques :<\/strong> Chaque action dans l&rsquo;environnement CI\/CD doit \u00eatre attribuable \u00e0 un individu. Les comptes de service partag\u00e9s doivent \u00eatre \u00e9limin\u00e9s ou compens\u00e9s par une journalisation suppl\u00e9mentaire et des contr\u00f4les maintenant la responsabilit\u00e9 individuelle.<\/li>\n\n\n\n<li><strong>Gestion des identifiants :<\/strong> Les identifiants du pipeline doivent \u00eatre renouvel\u00e9s \u00e0 des intervalles d\u00e9finis, stock\u00e9s de mani\u00e8re s\u00e9curis\u00e9e dans des syst\u00e8mes de gestion des secrets, jamais int\u00e9gr\u00e9s dans le code ou les fichiers de configuration, et imm\u00e9diatement r\u00e9voqu\u00e9s en cas de compromission ou lorsqu&rsquo;ils ne sont plus n\u00e9cessaires.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Exigence 10 \u2014 Journaliser et surveiller tous les acc\u00e8s<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Pistes d&rsquo;audit du pipeline :<\/strong> Toutes les activit\u00e9s du pipeline doivent \u00eatre journalis\u00e9es \u2014 builds, tests, d\u00e9ploiements, changements de configuration, octrois d&rsquo;acc\u00e8s et actions administratives. Les logs doivent inclure qui a effectu\u00e9 l&rsquo;action, ce qui a \u00e9t\u00e9 fait, quand cela s&rsquo;est produit et si cela a r\u00e9ussi ou \u00e9chou\u00e9.<\/li>\n\n\n\n<li><strong>Conservation des logs :<\/strong> PCI DSS exige un minimum de douze mois de conservation des logs d&rsquo;audit, avec au moins trois mois imm\u00e9diatement disponibles pour l&rsquo;analyse. Les logs du pipeline doivent respecter cette exigence.<\/li>\n\n\n\n<li><strong>Alertes :<\/strong> Des alertes automatis\u00e9es doivent \u00eatre configur\u00e9es pour les \u00e9v\u00e9nements de s\u00e9curit\u00e9 pertinents du pipeline \u2014 tentatives d&rsquo;authentification \u00e9chou\u00e9es, changements de configuration, \u00e9checs de d\u00e9ploiement, acc\u00e8s aux syst\u00e8mes sensibles et sch\u00e9mas d&rsquo;activit\u00e9 anormaux.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Exigence 11 \u2014 Tester r\u00e9guli\u00e8rement la s\u00e9curit\u00e9 des syst\u00e8mes et r\u00e9seaux<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Tests de p\u00e9n\u00e9tration :<\/strong> L&rsquo;infrastructure du pipeline dans le p\u00e9rim\u00e8tre PCI DSS doit \u00eatre incluse dans le programme de tests de p\u00e9n\u00e9tration de l&rsquo;organisation, avec des tests internes et externes r\u00e9alis\u00e9s au moins annuellement et apr\u00e8s des changements significatifs.<\/li>\n\n\n\n<li><strong>Analyse des vuln\u00e9rabilit\u00e9s :<\/strong> Les analyses de vuln\u00e9rabilit\u00e9s internes et externes doivent couvrir les composants du pipeline dans le p\u00e9rim\u00e8tre, avec les vuln\u00e9rabilit\u00e9s identifi\u00e9es rem\u00e9di\u00e9es et r\u00e9-analys\u00e9es pour confirmer la r\u00e9solution.<\/li>\n\n\n\n<li><strong>D\u00e9tection des changements :<\/strong> Des m\u00e9canismes doivent \u00eatre en place pour d\u00e9tecter les changements non autoris\u00e9s aux configurations de pipeline, scripts de d\u00e9ploiement et fichiers syst\u00e8me critiques. La surveillance de l&rsquo;int\u00e9grit\u00e9 des fichiers ou des contr\u00f4les \u00e9quivalents doivent couvrir l&rsquo;infrastructure du pipeline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Exigence 12 \u2014 Soutenir la s\u00e9curit\u00e9 de l&rsquo;information avec des politiques et programmes organisationnels<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Politiques de s\u00e9curit\u00e9 couvrant le CI\/CD :<\/strong> Les politiques de s\u00e9curit\u00e9 de l&rsquo;information de l&rsquo;organisation doivent traiter explicitement les environnements CI\/CD, y compris l&rsquo;utilisation acceptable, le contr\u00f4le d&rsquo;acc\u00e8s, la gestion des changements, la r\u00e9ponse aux incidents et la gestion des fournisseurs pour les composants du pipeline.<\/li>\n\n\n\n<li><strong>R\u00e9ponse aux incidents :<\/strong> Le plan de r\u00e9ponse aux incidents doit inclure des sc\u00e9narios pertinents pour le CI\/CD \u2014 compromission de pipeline, fuite de secrets, attaques de la cha\u00eene d&rsquo;approvisionnement et d\u00e9ploiements non autoris\u00e9s \u2014 avec des proc\u00e9dures de r\u00e9ponse d\u00e9finies, des responsabilit\u00e9s et des voies d&rsquo;escalade.<\/li>\n\n\n\n<li><strong>\u00c9valuations des risques :<\/strong> L&rsquo;\u00e9valuation des risques de l&rsquo;organisation doit couvrir les menaces sp\u00e9cifiques au CI\/CD, y compris les attaques de la cha\u00eene d&rsquo;approvisionnement, la compromission de pipeline, le vol d&rsquo;identifiants et la contamination d&rsquo;environnement. Les \u00e9valuations des risques doivent \u00eatre revues au moins annuellement et mises \u00e0 jour lorsque des changements significatifs surviennent.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Changements PCI DSS v4.0 impactant le CI\/CD<\/h2>\n\n\n\n<p>Plusieurs changements introduits dans PCI DSS v4.0 ont une signification particuli\u00e8re pour les environnements CI\/CD :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Approche personnalis\u00e9e :<\/strong> Les organisations peuvent d\u00e9sormais r\u00e9pondre aux exigences par des contr\u00f4les alternatifs, \u00e0 condition de d\u00e9montrer une s\u00e9curit\u00e9 \u00e9quivalente par une analyse de risque cibl\u00e9e. Cela est pr\u00e9cieux pour les environnements CI\/CD o\u00f9 les contr\u00f4les automatis\u00e9s et continus peuvent diff\u00e9rer des contr\u00f4les p\u00e9riodiques traditionnels d\u00e9crits dans l&rsquo;approche d\u00e9finie mais atteindre des r\u00e9sultats identiques ou meilleurs.<\/li>\n\n\n\n<li><strong>Analyse de risque cibl\u00e9e :<\/strong> v4.0 exige des analyses de risque cibl\u00e9es document\u00e9es pour des exigences sp\u00e9cifiques, permettant aux organisations de d\u00e9terminer la fr\u00e9quence de certaines activit\u00e9s (comme les revues d&rsquo;acc\u00e8s et les analyses de vuln\u00e9rabilit\u00e9s) en fonction de leur profil de risque plut\u00f4t que de suivre un calendrier unique.<\/li>\n\n\n\n<li><strong>Exigences \u00e0 date future (en vigueur depuis mars 2025) :<\/strong> Plusieurs exigences qui \u00e9taient des bonnes pratiques pendant la p\u00e9riode de transition sont devenues obligatoires en mars 2025. Celles-ci incluent des exigences d&rsquo;authentification renforc\u00e9es, des m\u00e9canismes automatis\u00e9s pour la revue des logs d&rsquo;audit et des processus de gestion des changements plus rigoureux \u2014 tous affectant directement les op\u00e9rations CI\/CD.<\/li>\n\n\n\n<li><strong>Exigences \u00e9volu\u00e9es de s\u00e9curit\u00e9 logicielle :<\/strong> v4.0 met davantage l&rsquo;accent sur les tests de s\u00e9curit\u00e9 automatis\u00e9s, l&rsquo;analyse de composition logicielle et la gouvernance des composants logiciels tiers \u2014 s&rsquo;alignant \u00e9troitement avec les pratiques DevSecOps modernes dans les pipelines CI\/CD.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Constats d&rsquo;\u00e9valuation courants<\/h2>\n\n\n\n<p>Les QSA identifient fr\u00e9quemment les probl\u00e8mes suivants lors de l&rsquo;\u00e9valuation des environnements CI\/CD par rapport aux exigences PCI DSS :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Acc\u00e8s non contr\u00f4l\u00e9 \u00e0 la production :<\/strong> Les d\u00e9veloppeurs ou comptes de service du pipeline ont un acc\u00e8s plus large aux syst\u00e8mes du CDE que n\u00e9cessaire, violant le principe du moindre privil\u00e8ge. L&rsquo;acc\u00e8s est accord\u00e9 par commodit\u00e9 plut\u00f4t que par besoin m\u00e9tier.<\/li>\n\n\n\n<li><strong>Conservation des logs manquante :<\/strong> Les logs du pipeline sont conserv\u00e9s pendant des semaines plut\u00f4t que les douze mois requis, ou les logs du d\u00e9but de la p\u00e9riode d&rsquo;\u00e9valuation ont \u00e9t\u00e9 purg\u00e9s et ne peuvent pas \u00eatre produits lors de la revue du QSA.<\/li>\n\n\n\n<li><strong>Aucune gestion des vuln\u00e9rabilit\u00e9s pour les composants du pipeline :<\/strong> Alors que le code applicatif est analys\u00e9, l&rsquo;infrastructure CI\/CD elle-m\u00eame \u2014 runners, plugins, images de base, outils de pipeline \u2014 n&rsquo;est pas incluse dans le programme de gestion des vuln\u00e9rabilit\u00e9s.<\/li>\n\n\n\n<li><strong>Chevauchement d&rsquo;environnements :<\/strong> Les environnements de d\u00e9veloppement et de production partagent des segments r\u00e9seau, des identifiants ou des runners de pipeline, compromettant la s\u00e9paration requise et cr\u00e9ant des voies d&rsquo;acc\u00e8s non autoris\u00e9 au CDE.<\/li>\n\n\n\n<li><strong>Preuves de gestion des changements inad\u00e9quates :<\/strong> Les changements sont d\u00e9ploy\u00e9s vers le CDE sans revue de code document\u00e9e, preuves de test ou enregistrements d&rsquo;approbation. Les proc\u00e9dures de changement d&rsquo;urgence existent mais sont utilis\u00e9es r\u00e9guli\u00e8rement sans revue post-impl\u00e9mentation.<\/li>\n\n\n\n<li><strong>Comptes partag\u00e9s dans les pipelines :<\/strong> Les comptes de service du pipeline sont partag\u00e9s entre \u00e9quipes ou environnements sans responsabilit\u00e9 individuelle, rendant impossible le tra\u00e7age d&rsquo;actions sp\u00e9cifiques \u00e0 des individus sp\u00e9cifiques.<\/li>\n\n\n\n<li><strong>P\u00e9rim\u00e8tre incomplet :<\/strong> Les syst\u00e8mes CI\/CD qui d\u00e9ploient vers ou affectent le CDE sont exclus de l&rsquo;\u00e9valuation du p\u00e9rim\u00e8tre PCI DSS, cr\u00e9ant des voies non contr\u00f4l\u00e9es vers l&rsquo;environnement de donn\u00e9es de titulaires de carte.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Articles approfondis<\/h2>\n\n\n\n<p>Explorez des conseils d\u00e9taill\u00e9s sur des aspects sp\u00e9cifiques de la conformit\u00e9 PCI DSS dans les environnements CI\/CD :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/fr\/ci-cd-governance\/pci-dss-v4-0-software-delivery-requirements-requirement-6-deep-dive\/\">PCI DSS v4.0 \u2014 Exigences de livraison logicielle (analyse approfondie de l&rsquo;exigence 6)<\/a> \u2014 Un examen d\u00e9taill\u00e9 des sous-exigences de l&rsquo;exigence 6 et leur traduction en contr\u00f4les et preuves de pipeline CI\/CD.<\/li>\n\n\n\n<li><a href=\"\/fr\/regulatory-frameworks\/pci-dss-and-ci-cd-what-qsas-need-to-verify\/\">PCI DSS et CI\/CD \u2014 Ce que les QSA doivent v\u00e9rifier<\/a> \u2014 Guide pratique sur les preuves, d\u00e9monstrations et documentation que les QSA attendent lors de l&rsquo;\u00e9valuation des environnements CI\/CD.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Contenu associ\u00e9<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/fr\/ci-cd-governance\/ci-cd-security-audit-compliance-mapping-nis2-pci-dss\/\">Correspondance de conformit\u00e9 : NIS2 \/ PCI DSS<\/a><\/li>\n\n\n\n<li><a href=\"\/fr\/regulatory-frameworks\/ci-cd-red-flags-by-regulation-explained\/\">Signaux d&rsquo;alerte CI\/CD par r\u00e9glementation<\/a><\/li>\n\n\n\n<li><a href=\"\/fr\/ci-cd-governance\/core-ci-cd-security-controls\/\">Contr\u00f4les de s\u00e9curit\u00e9 CI\/CD fondamentaux<\/a><\/li>\n\n\n\n<li><a href=\"\/fr\/regulatory-frameworks\/before-the-auditor-arrives-ci-cd-audit-readiness-checklist\/\">Avant l&rsquo;arriv\u00e9e de l&rsquo;auditeur \u2014 Checklist de pr\u00e9paration \u00e0 l&rsquo;audit CI\/CD<\/a><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">R\u00e9f\u00e9rences inter-r\u00e9f\u00e9rentiels<\/h2>\n\n\n\n<p>Les exigences PCI DSS chevauchent fr\u00e9quemment les contr\u00f4les d&rsquo;autres r\u00e9f\u00e9rentiels r\u00e9glementaires. Les organisations soumises \u00e0 plusieurs obligations de conformit\u00e9 peuvent construire un environnement de contr\u00f4le unifi\u00e9 qui satisfait PCI DSS parall\u00e8lement \u00e0 d&rsquo;autres normes :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/fr\/compliance\/iso-27001\/\">ISO 27001 et s\u00e9curit\u00e9 CI\/CD<\/a> \u2014 La norme SMSI internationale avec un chevauchement de contr\u00f4les \u00e9tendu, en particulier dans le contr\u00f4le d&rsquo;acc\u00e8s, la gestion des changements et le d\u00e9veloppement s\u00e9curis\u00e9<\/li>\n\n\n\n<li><a href=\"\/fr\/compliance\/soc-2\/\">SOC 2 et s\u00e9curit\u00e9 CI\/CD<\/a> \u2014 Crit\u00e8res de services de confiance avec un fort alignement sur les exigences PCI DSS en mati\u00e8re d&rsquo;acc\u00e8s logique, gestion des changements et surveillance<\/li>\n\n\n\n<li><a href=\"\/fr\/compliance\/dora\/\">DORA et s\u00e9curit\u00e9 CI\/CD<\/a> \u2014 Exigences du Digital Operational Resilience Act pour les entit\u00e9s financi\u00e8res, pertinentes lorsque le traitement des paiements croise la r\u00e9glementation financi\u00e8re de l&rsquo;UE<\/li>\n\n\n\n<li><a href=\"\/fr\/compliance\/nis2\/\">NIS2 et s\u00e9curit\u00e9 CI\/CD<\/a> \u2014 Exigences de la directive sur la s\u00e9curit\u00e9 des r\u00e9seaux et de l&rsquo;information pour les entit\u00e9s essentielles et importantes dans l&rsquo;UE<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>PCI DSS v4.0 : s\u00e9curiser la cha\u00eene de livraison logicielle pour les environnements de donn\u00e9es de titulaires de carte Le Payment Card Industry Data Security Standard (PCI DSS) v4.0 r\u00e9git toute organisation qui traite, stocke ou transmet des donn\u00e9es de titulaires de carte. Avec la version 4.0 d\u00e9sormais pleinement en vigueur \u2014 y compris les &#8230; <a title=\"PCI DSS et s\u00e9curit\u00e9 CI\/CD\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/fr\/compliance\/pci-dss\/\" aria-label=\"En savoir plus sur PCI DSS et s\u00e9curit\u00e9 CI\/CD\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":1460,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-1480","page","type-page","status-publish"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1480","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/comments?post=1480"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1480\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1460"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1480"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}