{"id":1384,"date":"2026-03-25T17:03:14","date_gmt":"2026-03-25T16:03:14","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/pci-dss-and-ci-cd-what-qsas-need-to-verify-2\/"},"modified":"2026-03-26T00:20:38","modified_gmt":"2026-03-25T23:20:38","slug":"pci-dss-and-ci-cd-what-qsas-need-to-verify","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/pci-dss-and-ci-cd-what-qsas-need-to-verify\/","title":{"rendered":"PCI DSS et CI\/CD \u2014 Ce que les QSA doivent v\u00e9rifier"},"content":{"rendered":"<h2>Perspective QSA : \u00c9valuer les environnements CI\/CD lors des \u00e9valuations PCI DSS<\/h2>\n<p>Alors que les Qualified Security Assessors (QSA) rencontrent des pipelines CI\/CD avec une fr\u00e9quence croissante dans les \u00e9valuations PCI DSS, le d\u00e9fi n&rsquo;est pas de savoir si ces syst\u00e8mes sont dans le p\u00e9rim\u00e8tre \u2014 mais comment les \u00e9valuer efficacement. Les m\u00e9thodologies d&rsquo;\u00e9valuation traditionnelles \u00e9taient con\u00e7ues pour des processus manuels de gestion des changements et une infrastructure statique. Les pipelines modernes de livraison logicielle n\u00e9cessitent que les \u00e9valuateurs comprennent les contr\u00f4les automatis\u00e9s, \u00e9valuent les preuves g\u00e9n\u00e9r\u00e9es par le syst\u00e8me et v\u00e9rifient que les m\u00e9canismes d&rsquo;application technique atteignent les objectifs de s\u00e9curit\u00e9 requis par PCI DSS.<\/p>\n<p>Cet article fournit une approche structur\u00e9e pour les QSA \u00e9valuant les environnements CI\/CD et pour les responsables conformit\u00e9 pr\u00e9parant leurs organisations \u00e0 de telles \u00e9valuations.<\/p>\n<h2>P\u00e9rim\u00e8tre CI\/CD pour PCI DSS : Quand les pipelines sont dans le p\u00e9rim\u00e8tre<\/h2>\n<p>Un pipeline CI\/CD est dans le p\u00e9rim\u00e8tre de PCI DSS lorsqu&rsquo;il r\u00e9pond \u00e0 l&rsquo;un des crit\u00e8res suivants :<\/p>\n<ul>\n<li><strong>D\u00e9ploie vers l&rsquo;environnement de donn\u00e9es des titulaires de cartes (CDE) :<\/strong> Tout pipeline qui d\u00e9ploie du code, de la configuration ou de l&rsquo;infrastructure vers des syst\u00e8mes qui traitent, stockent ou transmettent des donn\u00e9es de titulaires de cartes<\/li>\n<li><strong>Manipule des donn\u00e9es de titulaires de cartes :<\/strong> Pipelines qui traitent des donn\u00e9es de test contenant des PAN r\u00e9els, ou qui g\u00e8rent des cl\u00e9s de chiffrement ou des syst\u00e8mes de tokenisation<\/li>\n<li><strong>Pourrait affecter la s\u00e9curit\u00e9 du CDE :<\/strong> Pipelines d\u00e9ployant vers des syst\u00e8mes connect\u00e9s au CDE, m\u00eame s&rsquo;ils ne manipulent pas directement les donn\u00e9es de titulaires de cartes<\/li>\n<li><strong>G\u00e8re les contr\u00f4les de s\u00e9curit\u00e9 :<\/strong> Pipelines qui d\u00e9ploient ou configurent des pare-feux, WAF, IDS\/IPS ou autres contr\u00f4les de s\u00e9curit\u00e9 prot\u00e9geant le CDE<\/li>\n<\/ul>\n<p><strong>Principe cl\u00e9 de p\u00e9rim\u00e9trage :<\/strong> Si une compromission du pipeline pourrait conduire \u00e0 un acc\u00e8s non autoris\u00e9 aux donn\u00e9es de titulaires de cartes, le pipeline est dans le p\u00e9rim\u00e8tre.<\/p>\n<h2>M\u00e9thodologie d&rsquo;\u00e9valuation pour les contr\u00f4les CI\/CD<\/h2>\n<p>Une \u00e9valuation CI\/CD efficace suit une approche structur\u00e9e combinant revue de documentation, examen de configuration, \u00e9chantillonnage de preuves et entretiens avec le personnel.<\/p>\n<h3>Phase 1 : Revue de documentation<\/h3>\n<p>Demander et revoir : politique SDLC, proc\u00e9dures de gestion des changements, sch\u00e9mas d&rsquo;architecture du pipeline, documentation RBAC et proc\u00e9dures de r\u00e9ponse aux incidents couvrant le CI\/CD.<\/p>\n<h3>Phase 2 : Examen de configuration<\/h3>\n<p>Examiner directement : r\u00e8gles de protection de branche, configurations des portes de s\u00e9curit\u00e9 du pipeline, param\u00e8tres RBAC, politiques d&rsquo;application du MFA, configurations de journalisation et contr\u00f4les de s\u00e9gr\u00e9gation des environnements.<\/p>\n<h3>Phase 3 : \u00c9chantillonnage de preuves<\/h3>\n<p>S\u00e9lectionner des \u00e9chantillons sur la p\u00e9riode d&rsquo;\u00e9valuation pour v\u00e9rifier que les contr\u00f4les ont fonctionn\u00e9 de mani\u00e8re coh\u00e9rente. L&rsquo;\u00e9chantillonnage doit couvrir la p\u00e9riode compl\u00e8te et inclure diff\u00e9rents types de changements (normal, urgence, haut risque).<\/p>\n<h3>Phase 4 : Entretiens avec le personnel<\/h3>\n<p>Interviewer les responsables d&rsquo;\u00e9quipe de d\u00e9veloppement, les ing\u00e9nieurs s\u00e9curit\u00e9 et les administrateurs de pipeline pour v\u00e9rifier la compr\u00e9hension et l&rsquo;application coh\u00e9rente des contr\u00f4les.<\/p>\n<h2>Domaines d&rsquo;\u00e9valuation : Quoi demander, tester et \u00e9valuer<\/h2>\n<table>\n<thead>\n<tr>\n<th>Domaine d&rsquo;\u00e9valuation<\/th>\n<th>Quoi demander<\/th>\n<th>Quoi tester<\/th>\n<th>Crit\u00e8res de r\u00e9ussite\/\u00e9chec<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Preuves de d\u00e9veloppement s\u00e9curis\u00e9<\/td>\n<td>Documentation SDLC, enregistrements de formation, standards de codage s\u00e9curis\u00e9<\/td>\n<td>V\u00e9rifier que la formation est \u00e0 jour ; confirmer que le SDLC traite le CI\/CD ; v\u00e9rifier que les standards de codage sont appliqu\u00e9s via le pipeline<\/td>\n<td>R\u00e9ussite : SDLC document\u00e9, formation \u00e0 jour, application automatis\u00e9e. \u00c9chec : Pas de documentation SDLC, formation obsol\u00e8te, pas d&rsquo;application par le pipeline<\/td>\n<\/tr>\n<tr>\n<td>Gestion des vuln\u00e9rabilit\u00e9s<\/td>\n<td>Configurations d&rsquo;analyse, rapports de vuln\u00e9rabilit\u00e9s, enregistrements de rem\u00e9diation, artefacts SBOM<\/td>\n<td>V\u00e9rifier que les analyses s&rsquo;ex\u00e9cutent \u00e0 chaque build ; \u00e9chantillonner les vuln\u00e9rabilit\u00e9s pour la rapidit\u00e9 de rem\u00e9diation ; valider la compl\u00e9tude du SBOM<\/td>\n<td>R\u00e9ussite : Couverture d&rsquo;analyse \u00e0 100%, rem\u00e9diation dans les SLA, SBOM \u00e0 jour. \u00c9chec : Analyses manqu\u00e9es, violations de SLA, pas de SBOM<\/td>\n<\/tr>\n<tr>\n<td>Contr\u00f4le des changements<\/td>\n<td>Configuration du pipeline, journaux de d\u00e9ploiement, enregistrements d&rsquo;approbation, journal des changements d&rsquo;urgence<\/td>\n<td>\u00c9chantillonner les d\u00e9ploiements pour l&rsquo;approbation ; v\u00e9rifier l&rsquo;application SoD ; examiner les changements d&rsquo;urgence pour la documentation appropri\u00e9e<\/td>\n<td>R\u00e9ussite : Tous les changements approuv\u00e9s avant d\u00e9ploiement, SoD appliqu\u00e9e, changements d&rsquo;urgence document\u00e9s. \u00c9chec : D\u00e9ploiements non approuv\u00e9s, auto-approbations, urgences non document\u00e9es<\/td>\n<\/tr>\n<tr>\n<td>Contr\u00f4les d&rsquo;acc\u00e8s<\/td>\n<td>Configuration RBAC, enregistrements de revue d&rsquo;acc\u00e8s, inventaire des comptes de service, rapports d&rsquo;inscription MFA<\/td>\n<td>V\u00e9rifier le moindre privil\u00e8ge ; confirmer l&rsquo;application du MFA ; revoir la compl\u00e9tion des revues d&rsquo;acc\u00e8s et la rem\u00e9diation<\/td>\n<td>R\u00e9ussite : Moindre privil\u00e8ge appliqu\u00e9, MFA universel, revues \u00e0 jour avec rem\u00e9diation. \u00c9chec : Permissions excessives, lacunes MFA, revues manqu\u00e9es<\/td>\n<\/tr>\n<tr>\n<td>Journalisation et surveillance<\/td>\n<td>Configuration des journaux, param\u00e8tres de r\u00e9tention, r\u00e8gles d&rsquo;alerte, entr\u00e9es de journal \u00e9chantillonn\u00e9es<\/td>\n<td>V\u00e9rifier la compl\u00e9tude de la journalisation ; confirmer que la r\u00e9tention r\u00e9pond aux exigences ; tester la fonctionnalit\u00e9 des alertes<\/td>\n<td>R\u00e9ussite : Tous les \u00e9v\u00e9nements journalis\u00e9s, r\u00e9tention ad\u00e9quate, alertes fonctionnelles. \u00c9chec : Lacunes de journalisation, r\u00e9tention insuffisante, pas d&rsquo;alertes<\/td>\n<\/tr>\n<tr>\n<td>Chiffrement<\/td>\n<td>Configuration de chiffrement pour les secrets, param\u00e8tres de chiffrement en transit, proc\u00e9dures de gestion des cl\u00e9s<\/td>\n<td>V\u00e9rifier que les secrets sont chiffr\u00e9s au repos ; confirmer TLS pour toutes les communications du pipeline ; revoir la gestion des cl\u00e9s<\/td>\n<td>R\u00e9ussite : Tous les secrets chiffr\u00e9s, TLS appliqu\u00e9, gestion des cl\u00e9s document\u00e9e. \u00c9chec : Secrets en clair, communications non chiffr\u00e9es, pas de gestion des cl\u00e9s<\/td>\n<\/tr>\n<tr>\n<td>S\u00e9gr\u00e9gation des environnements<\/td>\n<td>Sch\u00e9mas d&rsquo;architecture, configuration r\u00e9seau, preuves de s\u00e9paration des identifiants<\/td>\n<td>V\u00e9rifier l&rsquo;isolation r\u00e9seau ; confirmer les identifiants s\u00e9par\u00e9s par environnement ; v\u00e9rifier que les contr\u00f4les de donn\u00e9es de test sont appliqu\u00e9s<\/td>\n<td>R\u00e9ussite : Isolation r\u00e9seau v\u00e9rifi\u00e9e, identifiants s\u00e9par\u00e9s, pas de donn\u00e9es r\u00e9elles en test. \u00c9chec : R\u00e9seaux partag\u00e9s, identifiants partag\u00e9s, PAN r\u00e9els en test<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Questions d&rsquo;entretien pour les \u00e9quipes de d\u00e9veloppement<\/h2>\n<p>Lors des entretiens avec le personnel de l&rsquo;\u00e9quipe de d\u00e9veloppement, les QSA doivent explorer les domaines suivants pour v\u00e9rifier que les contr\u00f4les document\u00e9s sont compris et suivis en pratique :<\/p>\n<h3>Gestion des changements<\/h3>\n<ul>\n<li>D\u00e9crivez le processus de d\u00e9ploiement d&rsquo;un changement en production. Quelles \u00e9tapes sont requises ?<\/li>\n<li>Que se passe-t-il si vous devez d\u00e9ployer un correctif d&rsquo;urgence en dehors des heures normales ?<\/li>\n<li>Pouvez-vous d\u00e9ployer en production sans revue de code ? Si oui, dans quelles circonstances ?<\/li>\n<li>Qui a l&rsquo;autorit\u00e9 d&rsquo;approuver les d\u00e9ploiements vers l&rsquo;environnement de donn\u00e9es des titulaires de cartes ?<\/li>\n<\/ul>\n<h3>Contr\u00f4les de s\u00e9curit\u00e9<\/h3>\n<ul>\n<li>Quelles analyses de s\u00e9curit\u00e9 s&rsquo;ex\u00e9cutent dans le cadre de votre pipeline ? Que se passe-t-il lorsqu&rsquo;une analyse trouve une vuln\u00e9rabilit\u00e9 critique ?<\/li>\n<li>Comment g\u00e9rez-vous les secrets et identifiants utilis\u00e9s par le pipeline ?<\/li>\n<li>Comment les environnements de d\u00e9veloppement, test et production sont-ils s\u00e9par\u00e9s ?<\/li>\n<li>Avez-vous d\u00e9j\u00e0 d\u00fb contourner une porte de s\u00e9curit\u00e9 ? Quel \u00e9tait le processus ?<\/li>\n<\/ul>\n<h3>Acc\u00e8s et authentification<\/h3>\n<ul>\n<li>Comment l&rsquo;acc\u00e8s aux syst\u00e8mes du pipeline est-il demand\u00e9 et approuv\u00e9 ?<\/li>\n<li>Quand a eu lieu votre derni\u00e8re revue d&rsquo;acc\u00e8s ? Des changements ont-ils \u00e9t\u00e9 effectu\u00e9s en cons\u00e9quence ?<\/li>\n<li>Le MFA est-il requis pour tout acc\u00e8s aux syst\u00e8mes du pipeline ? Y a-t-il des exceptions ?<\/li>\n<\/ul>\n<h3>R\u00e9ponse aux incidents<\/h3>\n<ul>\n<li>D\u00e9crivez ce qui se passerait si une vuln\u00e9rabilit\u00e9 de s\u00e9curit\u00e9 \u00e9tait d\u00e9couverte dans une application d\u00e9ploy\u00e9e<\/li>\n<li>Y a-t-il eu des incidents de s\u00e9curit\u00e9 impliquant le pipeline ? Comment ont-ils \u00e9t\u00e9 g\u00e9r\u00e9s ?<\/li>\n<\/ul>\n<h2>Strat\u00e9gie d&rsquo;\u00e9chantillonnage des preuves pour le CI\/CD<\/h2>\n<p>Un \u00e9chantillonnage efficace pour les \u00e9valuations CI\/CD n\u00e9cessite de prendre en compte le volume \u00e9lev\u00e9 et la nature automatis\u00e9e des activit\u00e9s du pipeline.<\/p>\n<h3>Directives d&rsquo;\u00e9chantillonnage<\/h3>\n<table>\n<thead>\n<tr>\n<th>Taille de la population (changements sur la p\u00e9riode)<\/th>\n<th>Taille d&rsquo;\u00e9chantillon recommand\u00e9e<\/th>\n<th>M\u00e9thode d&rsquo;\u00e9chantillonnage<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>1-50<\/td>\n<td>Tous les \u00e9l\u00e9ments<\/td>\n<td>Examen complet<\/td>\n<\/tr>\n<tr>\n<td>51-250<\/td>\n<td>25-30 \u00e9l\u00e9ments<\/td>\n<td>S\u00e9lection al\u00e9atoire sur toute la p\u00e9riode<\/td>\n<\/tr>\n<tr>\n<td>251-1 000<\/td>\n<td>30-40 \u00e9l\u00e9ments<\/td>\n<td>Al\u00e9atoire stratifi\u00e9 : distribution \u00e9gale sur les mois plus s\u00e9lection cibl\u00e9e des changements \u00e0 haut risque<\/td>\n<\/tr>\n<tr>\n<td>1 000+<\/td>\n<td>40-60 \u00e9l\u00e9ments<\/td>\n<td>Al\u00e9atoire stratifi\u00e9 sur les mois plus tous les changements d&rsquo;urgence plus s\u00e9lection cibl\u00e9e \u00e0 haut risque<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Ce qu&rsquo;il faut v\u00e9rifier dans chaque \u00e9chantillon<\/h3>\n<ul>\n<li>La revue de code a \u00e9t\u00e9 compl\u00e9t\u00e9e par un r\u00e9viseur qualifi\u00e9 qui n&rsquo;est pas l&rsquo;auteur<\/li>\n<li>L&rsquo;approbation a \u00e9t\u00e9 accord\u00e9e avant le d\u00e9ploiement par une personne autoris\u00e9e<\/li>\n<li>Les analyses de s\u00e9curit\u00e9 ont \u00e9t\u00e9 ex\u00e9cut\u00e9es et r\u00e9ussies (ou les \u00e9checs ont \u00e9t\u00e9 trait\u00e9s avant le d\u00e9ploiement)<\/li>\n<li>La documentation du changement est compl\u00e8te (description, impact, preuves de test)<\/li>\n<li>La s\u00e9paration des t\u00e2ches a \u00e9t\u00e9 maintenue tout au long du cycle de vie du changement<\/li>\n<\/ul>\n<h2>Signaux d&rsquo;alerte indiquant la non-conformit\u00e9<\/h2>\n<p>Lors de l&rsquo;\u00e9valuation, les constats suivants doivent susciter une pr\u00e9occupation imm\u00e9diate :<\/p>\n<ul>\n<li><strong>Horodatages d&rsquo;approbation post\u00e9rieurs aux horodatages de d\u00e9ploiement :<\/strong> Indique une approbation r\u00e9troactive \u2014 changements d\u00e9ploy\u00e9s avant autorisation<\/li>\n<li><strong>M\u00eame individu comme auteur et approbateur :<\/strong> Violation de la s\u00e9paration des t\u00e2ches<\/li>\n<li><strong>R\u00e9sultats d&rsquo;analyse de s\u00e9curit\u00e9 montrant des contournements syst\u00e9matiques :<\/strong> Sugg\u00e8re que les contr\u00f4les existent mais sont syst\u00e9matiquement contourn\u00e9s<\/li>\n<li><strong>Pas de documentation de changement d&rsquo;urgence malgr\u00e9 des preuves de d\u00e9ploiements hors heures :<\/strong> Indique des contournements non document\u00e9s des proc\u00e9dures normales de changement<\/li>\n<li><strong>Comptes de service avec acc\u00e8s administratif \u00e0 plusieurs environnements :<\/strong> Viole le moindre privil\u00e8ge et la s\u00e9gr\u00e9gation des environnements<\/li>\n<li><strong>Lacunes dans la journalisation pendant la p\u00e9riode d&rsquo;\u00e9valuation :<\/strong> Peut indiquer une falsification de preuves ou des d\u00e9faillances de configuration<\/li>\n<li><strong>Revues d&rsquo;acc\u00e8s ne montrant aucun changement n\u00e9cessaire :<\/strong> Peut indiquer que les revues sont superficielles plut\u00f4t que substantielles<\/li>\n<li><strong>Changements de configuration du pipeline non soumis \u00e0 la gestion des changements :<\/strong> L&rsquo;environnement de contr\u00f4le lui-m\u00eame n&rsquo;est pas contr\u00f4l\u00e9<\/li>\n<li><strong>D\u00e9veloppeurs avec acc\u00e8s direct \u00e0 la production en dehors du pipeline :<\/strong> Indique que le pipeline peut \u00eatre enti\u00e8rement contourn\u00e9<\/li>\n<\/ul>\n<h2>Contr\u00f4les compensatoires et consid\u00e9rations d&rsquo;approche personnalis\u00e9e<\/h2>\n<h3>Contr\u00f4les compensatoires<\/h3>\n<p>Lorsqu&rsquo;une organisation ne peut pas r\u00e9pondre \u00e0 une exigence PCI DSS telle qu&rsquo;\u00e9nonc\u00e9e, les contr\u00f4les compensatoires peuvent \u00eatre acceptables s&rsquo;ils :<\/p>\n<ul>\n<li>R\u00e9pondent \u00e0 l&rsquo;intention et \u00e0 la rigueur de l&rsquo;exigence originale<\/li>\n<li>Fournissent un niveau de d\u00e9fense similaire<\/li>\n<li>Vont au-del\u00e0 des autres exigences PCI DSS<\/li>\n<li>Sont proportionn\u00e9s au risque suppl\u00e9mentaire caus\u00e9 par le non-respect de l&rsquo;exigence originale<\/li>\n<\/ul>\n<p><strong>Exemple :<\/strong> Si un outil de pipeline legacy ne peut pas appliquer techniquement la s\u00e9paration des t\u00e2ches, les contr\u00f4les compensatoires pourraient inclure une revue post-d\u00e9ploiement obligatoire par une partie ind\u00e9pendante, une journalisation am\u00e9lior\u00e9e avec alertes en temps r\u00e9el sur les changements auto-approuv\u00e9s et un audit mensuel de tous les enregistrements de d\u00e9ploiement.<\/p>\n<h3>Approche personnalis\u00e9e (v4.0)<\/h3>\n<p>L&rsquo;approche personnalis\u00e9e permet aux organisations de r\u00e9pondre \u00e0 l&rsquo;objectif de s\u00e9curit\u00e9 par des moyens alternatifs. Pour les environnements CI\/CD, cela offre de la flexibilit\u00e9 mais n\u00e9cessite :<\/p>\n<ul>\n<li>Une analyse cibl\u00e9e des risques document\u00e9e pour chaque contr\u00f4le personnalis\u00e9<\/li>\n<li>Une articulation claire de la mani\u00e8re dont le contr\u00f4le alternatif atteint l&rsquo;objectif de s\u00e9curit\u00e9<\/li>\n<li>Des preuves que le contr\u00f4le personnalis\u00e9 est au moins aussi efficace que l&rsquo;approche d\u00e9finie<\/li>\n<li>Des tests plus rigoureux par le QSA pour valider le contr\u00f4le personnalis\u00e9<\/li>\n<\/ul>\n<h2>Documentation du rapport de conformit\u00e9 (ROC) pour les contr\u00f4les CI\/CD<\/h2>\n<p>Lors de la documentation des contr\u00f4les CI\/CD dans le ROC, les QSA doivent s&rsquo;assurer :<\/p>\n<ul>\n<li><strong>D\u00e9finition du p\u00e9rim\u00e8tre :<\/strong> Documenter clairement quels composants du pipeline sont dans le p\u00e9rim\u00e8tre et la justification des d\u00e9cisions de p\u00e9rim\u00e9trage<\/li>\n<li><strong>Descriptions des contr\u00f4les :<\/strong> D\u00e9crire comment les contr\u00f4les CI\/CD satisfont chaque exigence pertinente, incluant les m\u00e9canismes d&rsquo;application technique<\/li>\n<li><strong>R\u00e9f\u00e9rences de preuves :<\/strong> R\u00e9f\u00e9rencer les preuves sp\u00e9cifiques examin\u00e9es, incluant les journaux g\u00e9n\u00e9r\u00e9s par le syst\u00e8me, les captures d&rsquo;\u00e9cran de configuration et les enregistrements \u00e9chantillonn\u00e9s<\/li>\n<li><strong>Proc\u00e9dures de test :<\/strong> Documenter la m\u00e9thodologie d&rsquo;\u00e9valuation utilis\u00e9e, incluant l&rsquo;approche d&rsquo;\u00e9chantillonnage et les tailles d&rsquo;\u00e9chantillon<\/li>\n<li><strong>Constats et observations :<\/strong> Documenter toute exception, contr\u00f4le compensatoire ou domaine o\u00f9 l&rsquo;approche personnalis\u00e9e a \u00e9t\u00e9 utilis\u00e9e<\/li>\n<li><strong>R\u00e9sum\u00e9s d&rsquo;entretiens :<\/strong> Documenter les constats cl\u00e9s des entretiens avec le personnel, en particulier lorsque les r\u00e9ponses aux entretiens ont confirm\u00e9 ou contredit les preuves documentaires<\/li>\n<\/ul>\n<h2>Ressources connexes<\/h2>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/pci-dss\/\">Hub de conformit\u00e9 PCI DSS<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/ci-cd-audit-red-flags-what-immediately-raises-auditor-concerns\/\">Signaux d&rsquo;alerte d&rsquo;audit CI\/CD \u2014 Ce qui pr\u00e9occupe imm\u00e9diatement les auditeurs<\/a><\/li>\n<\/ul>\n<hr\/>\n<h3>Ressources connexes pour les auditeurs<\/h3>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossaire<\/a> \u2014 D\u00e9finitions en langage clair des termes techniques<\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/how-auditors-actually-review-ci-cd-pipelines\/\">Comment les auditeurs examinent le CI\/CD<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/before-the-auditor-arrives-ci-cd-audit-readiness-checklist\/\">Checklist de pr\u00e9paration \u00e0 l&rsquo;audit<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/audit-day-playbook-how-to-handle-ci-cd-audits-in-regulated-environments\/\">Guide du jour d&rsquo;audit<\/a><\/li>\n<\/ul>\n<p><em>Nouveau dans l&rsquo;audit CI\/CD ? Commencez par notre <a href=\"https:\/\/regulated-devsecops.com\/fr\/start-here\/\">Guide de l&rsquo;auditeur<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Perspective QSA : \u00c9valuer les environnements CI\/CD lors des \u00e9valuations PCI DSS Alors que les Qualified Security Assessors (QSA) rencontrent des pipelines CI\/CD avec une fr\u00e9quence croissante dans les \u00e9valuations PCI DSS, le d\u00e9fi n&rsquo;est pas de savoir si ces syst\u00e8mes sont dans le p\u00e9rim\u00e8tre \u2014 mais comment les \u00e9valuer efficacement. Les m\u00e9thodologies d&rsquo;\u00e9valuation traditionnelles &#8230; <a title=\"PCI DSS et CI\/CD \u2014 Ce que les QSA doivent v\u00e9rifier\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/pci-dss-and-ci-cd-what-qsas-need-to-verify\/\" aria-label=\"En savoir plus sur PCI DSS et CI\/CD \u2014 Ce que les QSA doivent v\u00e9rifier\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[122,126],"tags":[],"post_folder":[],"class_list":["post-1384","post","type-post","status-publish","format-standard","hentry","category-audit-evidence","category-regulatory-frameworks"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1384","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"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=1384"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1384\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1384"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/categories?post=1384"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/tags?post=1384"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/post_folder?post=1384"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}