PCI DSS et sécurité CI/CD

PCI DSS v4.0 : sécuriser la chaîne de livraison logicielle pour les environnements de données de titulaires de carte

Le Payment Card Industry Data Security Standard (PCI DSS) v4.0 régit toute organisation qui traite, stocke ou transmet des données de titulaires de carte. Avec la version 4.0 désormais pleinement en vigueur — y compris les exigences à date future devenues obligatoires en mars 2025 — la norme met un accent considérablement plus important sur la sécurisation du cycle de développement et de déploiement des logiciels. Pour les organisations livrant des applications vers l’environnement de données de titulaires de carte (CDE) via des pipelines CI/CD, le pipeline lui-même devient un composant critique dans le périmètre d’évaluation.

Cette page hub fournit des conseils complets sur l’alignement des contrôles de sécurité CI/CD avec les exigences PCI DSS v4.0, la compréhension des implications de périmètre, la préparation aux examens du Qualified Security Assessor (QSA) et le traitement des constats d’évaluation les plus courants dans les environnements de livraison logicielle.

Aperçu PCI DSS v4.0

PCI DSS v4.0 est structuré autour de 12 exigences principales, organisées en six objectifs de contrôle. La norme s’applique à toutes les entités impliquées dans le traitement des cartes de paiement — commerçants, prestataires de services, acquéreurs et émetteurs — le niveau d’évaluation étant déterminé par le volume de transactions et le type d’entité.

Méthodes d’évaluation

  • Self-Assessment Questionnaire (SAQ) : Un outil d’auto-validation pour les petits commerçants et prestataires de services répondant à des critères d’éligibilité spécifiques. Plusieurs types de SAQ existent selon la manière dont les données de titulaires de carte sont traitées.
  • Report on Compliance (ROC) : Une évaluation détaillée réalisée par un QSA, requise pour les commerçants et prestataires de services de niveau 1. Le ROC documente les constats de l’évaluateur par rapport à chaque exigence applicable.
  • Qualified Security Assessor (QSA) : Un évaluateur indépendant certifié par le PCI Security Standards Council pour évaluer la conformité. Les QSA réalisent des évaluations sur site, examinent les preuves, interrogent le personnel et observent les processus.

L’approche personnalisée

PCI DSS v4.0 introduit une approche personnalisée comme alternative à l’approche définie pour répondre aux exigences. Les organisations peuvent mettre en œuvre des contrôles différents de l’approche prescriptive définie, à condition de pouvoir démontrer par une analyse de risque ciblée que leurs contrôles répondent à l’objectif de chaque exigence. Cela est particulièrement pertinent pour les environnements CI/CD où les pratiques DevSecOps modernes peuvent atteindre le même résultat de sécurité par des moyens différents de ceux prescrits dans l’approche définie.

Quand le CI/CD est dans le périmètre PCI DSS

Le périmètre PCI DSS détermine quels systèmes, processus et personnes sont soumis à l’évaluation. Les pipelines CI/CD entrent dans le périmètre lorsqu’ils :

  • Déploient vers le CDE : Les pipelines qui livrent du code, de la configuration ou des changements d’infrastructure vers des systèmes qui traitent, stockent ou transmettent des données de titulaires de carte sont directement dans le périmètre.
  • Manipulent des données de titulaires de carte : Les pipelines qui traitent des données de test contenant de vrais PAN, ou qui gèrent des clés de chiffrement ou des systèmes de tokenisation, sont dans le périmètre.
  • Se connectent aux systèmes du CDE : Les pipelines qui ont une connectivité réseau vers le CDE — même s’ils ne manipulent pas directement les données de titulaires de carte — peuvent être classés comme systèmes connectés ou ayant un impact sur la sécurité.
  • Affectent la sécurité du CDE : Les pipelines qui gèrent les contrôles de sécurité, les règles de pare-feu, les configurations d’accès ou les systèmes de surveillance du CDE ont un impact sur la sécurité et sont donc dans le périmètre.

Considérations de segmentation

Les organisations peuvent réduire leur périmètre PCI DSS par la segmentation réseau — en isolant le CDE des autres systèmes. Pour le CI/CD, cela signifie envisager si l’infrastructure du pipeline peut être segmentée de sorte que seules des étapes ou runners spécifiques du pipeline aient accès au CDE. Cependant, les composants du pipeline qui déploient vers ou configurent le CDE resteront dans le périmètre indépendamment de la segmentation. La segmentation elle-même doit être validée dans le cadre de l’évaluation, et les QSA vérifieront que les systèmes de pipeline en dehors du périmètre défini du CDE ne peuvent véritablement pas affecter la sécurité des données de titulaires de carte.

Exigences clés pour les environnements CI/CD

Exigence 6 — Développer et maintenir des systèmes et logiciels sécurisés

L’exigence 6 est l’exigence la plus directement pertinente pour les pipelines CI/CD et couvre l’ensemble du cycle de développement et de déploiement logiciel :

  • 6.2 Développement sécurisé : Des pratiques de codage sécurisé doivent être définies et appliquées. Les développeurs doivent être formés aux techniques de codage sécurisé pertinentes pour les technologies utilisées. L’organisation doit maintenir des standards de codage sécurisé appliqués via le pipeline — pas seulement documentés dans une politique.
  • 6.3 Gestion des vulnérabilités : Les vulnérabilités dans le code personnalisé et les composants tiers doivent être identifiées, priorisées et remédiées dans des délais définis. Cela inclut le maintien d’un inventaire des composants tiers (SBOM), la surveillance des divulgations de vulnérabilités et l’application rapide des correctifs. Les pipelines CI/CD doivent intégrer l’analyse des vulnérabilités (SCA) et bloquer les déploiements lorsque des vulnérabilités critiques sont identifiées.
  • 6.4 Applications web exposées au public : Les applications exposées sur Internet doivent être protégées contre les attaques courantes. Cela inclut l’intégration de DAST dans le pipeline de déploiement, la réalisation d’évaluations régulières des vulnérabilités et le déploiement de pare-feu d’applications web (WAF) le cas échéant.
  • 6.5 Gestion des changements : Tous les changements aux composants système dans le CDE doivent suivre un processus documenté de gestion des changements. Cela inclut la revue de code par des personnes autres que l’auteur, l’approbation documentée avant le déploiement en production, les tests fonctionnels pour vérifier que les changements fonctionnent comme prévu et les procédures de retour en arrière. Les pipelines CI/CD doivent imposer ces exigences via des contrôles techniques — protection de branche, revues obligatoires, portes d’approbation et tests automatisés.
  • Intégration SAST et DAST : Les tests de sécurité statique doivent être effectués sur le code personnalisé avant la release, et les tests dynamiques doivent être réalisés sur les applications déployées. L’intégration dans le pipeline garantit que ces exigences sont respectées de manière cohérente pour chaque release.

Exigence 7 — Restreindre l’accès aux composants système et aux données de titulaires de carte

  • Moindre privilège : L’accès aux systèmes de pipeline qui déploient vers le CDE doit être restreint au minimum nécessaire pour chaque rôle. Les comptes de service du pipeline ne doivent avoir que les permissions requises pour leur fonction spécifique.
  • RBAC : Le contrôle d’accès doit être basé sur les rôles avec des définitions de rôles documentées, des octrois d’accès approuvés et des revues régulières pour identifier et remédier les permissions excessives.
  • Provisionnement et déprovisionnement d’accès : Des processus doivent exister pour accorder l’accès au nouveau personnel et supprimer rapidement l’accès lors de changements de rôle ou de départ du personnel. Cela s’applique aux comptes de plateforme CI/CD, à l’accès aux dépôts et aux identifiants de déploiement.

Exigence 8 — Identifier les utilisateurs et authentifier les accès

  • MFA pour l’accès administratif : Tout accès administratif aux systèmes de pipeline, y compris la configuration de la plateforme CI/CD, la gestion des secrets et les contrôles de déploiement en production, doit nécessiter l’authentification multifacteur.
  • Pas de comptes partagés ou génériques : Chaque action dans l’environnement CI/CD doit être attribuable à un individu. Les comptes de service partagés doivent être éliminés ou compensés par une journalisation supplémentaire et des contrôles maintenant la responsabilité individuelle.
  • Gestion des identifiants : Les identifiants du pipeline doivent être renouvelés à des intervalles définis, stockés de manière sécurisée dans des systèmes de gestion des secrets, jamais intégrés dans le code ou les fichiers de configuration, et immédiatement révoqués en cas de compromission ou lorsqu’ils ne sont plus nécessaires.

Exigence 10 — Journaliser et surveiller tous les accès

  • Pistes d’audit du pipeline : Toutes les activités du pipeline doivent être journalisées — builds, tests, déploiements, changements de configuration, octrois d’accès et actions administratives. Les logs doivent inclure qui a effectué l’action, ce qui a été fait, quand cela s’est produit et si cela a réussi ou échoué.
  • Conservation des logs : PCI DSS exige un minimum de douze mois de conservation des logs d’audit, avec au moins trois mois immédiatement disponibles pour l’analyse. Les logs du pipeline doivent respecter cette exigence.
  • Alertes : Des alertes automatisées doivent être configurées pour les événements de sécurité pertinents du pipeline — tentatives d’authentification échouées, changements de configuration, échecs de déploiement, accès aux systèmes sensibles et schémas d’activité anormaux.

Exigence 11 — Tester régulièrement la sécurité des systèmes et réseaux

  • Tests de pénétration : L’infrastructure du pipeline dans le périmètre PCI DSS doit être incluse dans le programme de tests de pénétration de l’organisation, avec des tests internes et externes réalisés au moins annuellement et après des changements significatifs.
  • Analyse des vulnérabilités : Les analyses de vulnérabilités internes et externes doivent couvrir les composants du pipeline dans le périmètre, avec les vulnérabilités identifiées remédiées et ré-analysées pour confirmer la résolution.
  • Détection des changements : Des mécanismes doivent être en place pour détecter les changements non autorisés aux configurations de pipeline, scripts de déploiement et fichiers système critiques. La surveillance de l’intégrité des fichiers ou des contrôles équivalents doivent couvrir l’infrastructure du pipeline.

Exigence 12 — Soutenir la sécurité de l’information avec des politiques et programmes organisationnels

  • Politiques de sécurité couvrant le CI/CD : Les politiques de sécurité de l’information de l’organisation doivent traiter explicitement les environnements CI/CD, y compris l’utilisation acceptable, le contrôle d’accès, la gestion des changements, la réponse aux incidents et la gestion des fournisseurs pour les composants du pipeline.
  • Réponse aux incidents : Le plan de réponse aux incidents doit inclure des scénarios pertinents pour le CI/CD — compromission de pipeline, fuite de secrets, attaques de la chaîne d’approvisionnement et déploiements non autorisés — avec des procédures de réponse définies, des responsabilités et des voies d’escalade.
  • Évaluations des risques : L’évaluation des risques de l’organisation doit couvrir les menaces spécifiques au CI/CD, y compris les attaques de la chaîne d’approvisionnement, la compromission de pipeline, le vol d’identifiants et la contamination d’environnement. Les évaluations des risques doivent être revues au moins annuellement et mises à jour lorsque des changements significatifs surviennent.

Changements PCI DSS v4.0 impactant le CI/CD

Plusieurs changements introduits dans PCI DSS v4.0 ont une signification particulière pour les environnements CI/CD :

  • Approche personnalisée : Les organisations peuvent désormais répondre aux exigences par des contrôles alternatifs, à condition de démontrer une sécurité équivalente par une analyse de risque ciblée. Cela est précieux pour les environnements CI/CD où les contrôles automatisés et continus peuvent différer des contrôles périodiques traditionnels décrits dans l’approche définie mais atteindre des résultats identiques ou meilleurs.
  • Analyse de risque ciblée : v4.0 exige des analyses de risque ciblées documentées pour des exigences spécifiques, permettant aux organisations de déterminer la fréquence de certaines activités (comme les revues d’accès et les analyses de vulnérabilités) en fonction de leur profil de risque plutôt que de suivre un calendrier unique.
  • Exigences à date future (en vigueur depuis mars 2025) : Plusieurs exigences qui étaient des bonnes pratiques pendant la période de transition sont devenues obligatoires en mars 2025. Celles-ci incluent des exigences d’authentification renforcées, des mécanismes automatisés pour la revue des logs d’audit et des processus de gestion des changements plus rigoureux — tous affectant directement les opérations CI/CD.
  • Exigences évoluées de sécurité logicielle : v4.0 met davantage l’accent sur les tests de sécurité automatisés, l’analyse de composition logicielle et la gouvernance des composants logiciels tiers — s’alignant étroitement avec les pratiques DevSecOps modernes dans les pipelines CI/CD.

Constats d’évaluation courants

Les QSA identifient fréquemment les problèmes suivants lors de l’évaluation des environnements CI/CD par rapport aux exigences PCI DSS :

  • Accès non contrôlé à la production : Les développeurs ou comptes de service du pipeline ont un accès plus large aux systèmes du CDE que nécessaire, violant le principe du moindre privilège. L’accès est accordé par commodité plutôt que par besoin métier.
  • Conservation des logs manquante : Les logs du pipeline sont conservés pendant des semaines plutôt que les douze mois requis, ou les logs du début de la période d’évaluation ont été purgés et ne peuvent pas être produits lors de la revue du QSA.
  • Aucune gestion des vulnérabilités pour les composants du pipeline : Alors que le code applicatif est analysé, l’infrastructure CI/CD elle-même — runners, plugins, images de base, outils de pipeline — n’est pas incluse dans le programme de gestion des vulnérabilités.
  • Chevauchement d’environnements : Les environnements de développement et de production partagent des segments réseau, des identifiants ou des runners de pipeline, compromettant la séparation requise et créant des voies d’accès non autorisé au CDE.
  • Preuves de gestion des changements inadéquates : Les changements sont déployés vers le CDE sans revue de code documentée, preuves de test ou enregistrements d’approbation. Les procédures de changement d’urgence existent mais sont utilisées régulièrement sans revue post-implémentation.
  • Comptes partagés dans les pipelines : Les comptes de service du pipeline sont partagés entre équipes ou environnements sans responsabilité individuelle, rendant impossible le traçage d’actions spécifiques à des individus spécifiques.
  • Périmètre incomplet : Les systèmes CI/CD qui déploient vers ou affectent le CDE sont exclus de l’évaluation du périmètre PCI DSS, créant des voies non contrôlées vers l’environnement de données de titulaires de carte.

Articles approfondis

Explorez des conseils détaillés sur des aspects spécifiques de la conformité PCI DSS dans les environnements CI/CD :

Contenu associé

Références inter-référentiels

Les exigences PCI DSS chevauchent fréquemment les contrôles d’autres référentiels réglementaires. Les organisations soumises à plusieurs obligations de conformité peuvent construire un environnement de contrôle unifié qui satisfait PCI DSS parallèlement à d’autres normes :

  • ISO 27001 et sécurité CI/CD — La norme SMSI internationale avec un chevauchement de contrôles étendu, en particulier dans le contrôle d’accès, la gestion des changements et le développement sécurisé
  • SOC 2 et sécurité CI/CD — Critères de services de confiance avec un fort alignement sur les exigences PCI DSS en matière d’accès logique, gestion des changements et surveillance
  • DORA et sécurité CI/CD — Exigences du Digital Operational Resilience Act pour les entités financières, pertinentes lorsque le traitement des paiements croise la réglementation financière de l’UE
  • NIS2 et sécurité CI/CD — Exigences de la directive sur la sécurité des réseaux et de l’information pour les entités essentielles et importantes dans l’UE