Aperçu : Exigence 6 de PCI DSS v4.0
L’exigence 6 de PCI DSS v4.0 — Développer et maintenir des systèmes et logiciels sécurisés — 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ées de titulaires de cartes. Cette exigence établit des attentes pour les pratiques de développement sécurisé, la gestion des vulnérabilités, le contrôle des changements et les tests de sécurité applicatifs.
Pour les responsables conformité et les auditeurs, comprendre comment chaque sous-exigence se rapporte aux contrôles CI/CD est essentiel tant pour implémenter des pipelines conformes que pour vérifier la conformité lors des évaluations.
Sous-exigence 6.1 : Établir et maintenir des processus de développement sécurisé
L’exigence 6.1 impose que les organisations établissent, documentent et maintiennent des processus d’identification des vulnérabilités de sécurité et de développement de systèmes et logiciels sécurisés.
Pertinence CI/CD
- Cycle de développement sécurisé (SDLC) documenté : Le SDLC doit explicitement aborder comment les pipelines CI/CD appliquent les pratiques de développement sécurisé
- Revue annuelle des processus de développement : Les contrôles et configurations de sécurité du pipeline doivent être révisés au moins annuellement et mis à jour lorsque l’environnement change
- Formation du personnel de développement : Les équipes doivent être formées aux pratiques de codage sécurisé et à l’utilisation efficace des outils de sécurité du pipeline
Preuves pour l’évaluation
- Politique SDLC documentée référençant les contrôles de sécurité CI/CD
- Enregistrements de revue annuelle avec changements identifiés et approbations
- Enregistrements de complétion de formation pour le personnel de développement
Sous-exigence 6.2 : Développer des logiciels de manière sécurisée
L’exigence 6.2 traite des pratiques à suivre pendant le développement logiciel, incluant le codage sécurisé, la revue de code et les tests de sécurité.
Pertinence CI/CD
- Standards de codage sécurisé : Application par le pipeline des standards de codage via le linting automatisé et l’analyse statique
- Revue de code avant publication : Revue par les pairs obligatoire appliquée via la protection de branche et les exigences de merge request
- Intégration des tests de sécurité : SAST, SCA et détection de secrets intégrés dans le pipeline avec des critères de réussite/échec définis
- Séparation des environnements de développement, test et production : L’architecture du pipeline doit appliquer la ségrégation des environnements
Preuves pour l’évaluation
- Configuration du pipeline montrant les étapes d’analyse de sécurité
- Règles de protection de branche exigeant la revue de code
- Résultats d’analyse de sécurité et journaux d’application des portes
- Documentation d’architecture des environnements démontrant la ségrégation
Sous-exigence 6.3 : Identifier et gérer les vulnérabilités de sécurité
L’exigence 6.3 se concentre sur l’identification des vulnérabilités, le classement des risques et la remédiation rapide sur tous les composants système.
Pertinence CI/CD
- Analyse des vulnérabilités du code personnalisé : L’analyse automatisée des vulnérabilités doit faire partie du processus de build
- Gestion des vulnérabilités des composants tiers : L’analyse des dépendances doit identifier les vulnérabilités connues dans les bibliothèques et frameworks consommés via le pipeline
- Remédiation classée par risque : Les portes du pipeline doivent appliquer les délais de remédiation basés sur la gravité des vulnérabilités (les vulnérabilités critiques/élevées bloquent le déploiement)
- Gestion des correctifs : L’infrastructure du pipeline elle-même (outils de build, runners, images de conteneurs) doit être corrigée et mise à jour
Changements spécifiques v4.0
PCI DSS v4.0 introduit des exigences plus prescriptives concernant les délais de gestion des vulnérabilités. Les vulnérabilités critiques et de haute gravité doivent être traitées rapidement, et les organisations doivent définir et suivre leurs propres délais de remédiation basés sur le classement des risques.
Sous-exigence 6.4 : Protéger les applications web exposées au public
L’exigence 6.4 exige la protection des applications web exposées au public contre les attaques connues, soit par des évaluations de vulnérabilité manuelles/automatisées, soit par des pare-feux d’applications web.
Pertinence CI/CD
- Intégration DAST : Les tests dynamiques de sécurité applicative peuvent être intégrés dans les pipelines de déploiement pour les environnements de staging ou de pré-production
- Automatisation du déploiement WAF : Déploiement et configuration des règles WAF gérés par le pipeline
- Planification des évaluations de vulnérabilité : Évaluations automatisées des vulnérabilités déclenchées par les déploiements ou selon des calendriers définis
Changements spécifiques v4.0
PCI DSS v4.0 (spécifiquement 6.4.2) exige des solutions techniques automatisées pour les applications web exposées au public qui détectent et préviennent continuellement les attaques basées sur le web. Il s’agit d’une exigence à date future devenue obligatoire après le 31 mars 2025.
Sous-exigence 6.5 : Gérer les changements des composants système
L’exigence 6.5 établit des exigences de gestion des changements qui régissent directement le fonctionnement des pipelines CI/CD.
Pertinence CI/CD
- Procédures documentées de contrôle des changements : Le pipeline lui-même doit être régi par une procédure documentée de contrôle des changements
- Analyse d’impact : Les changements doivent inclure une documentation d’impact, y compris l’impact sécurité
- Approbation autorisée : Tous les changements aux systèmes de production doivent être formellement approuvés par du personnel autorisé
- Exigences de test : Les changements doivent être testés avant le déploiement en production, avec les tests vérifiés via les portes du pipeline
- Procédures de rollback : Procédures documentées pour annuler les changements causant des problèmes
- Ségrégation du développement, du test et de la production : L’architecture du pipeline doit empêcher les données de test ou les configurations de développement d’atteindre la production
Cartographie complète : Sous-exigence vers contrôle CI/CD
| Sous-exigence PCI DSS | Contrôle CI/CD | Preuves | Méthode de vérification QSA |
|---|---|---|---|
| 6.1.1 — Rôles de sécurité définis | Rôles RBAC pour l’accès et les opérations du pipeline | Définitions de rôles, configuration RBAC | Revoir la documentation des rôles ; vérifier la correspondance de la configuration |
| 6.1.2 — Revue annuelle des processus | Processus de revue annuelle de sécurité du pipeline | Enregistrements de revue, journal des changements, enregistrements d’approbation | Examiner la documentation de revue ; confirmer que le périmètre inclut le CI/CD |
| 6.2.1 — Formation au codage sécurisé | Formation des développeurs aux outils de sécurité du pipeline et au codage sécurisé | Enregistrements de formation, certificats de complétion | Échantillonner les enregistrements de formation ; interviewer les développeurs |
| 6.2.2 — Revue de code avant production | Revue par les pairs obligatoire via la protection de branche | Configuration de protection de branche, journaux de merge request | Vérifier la configuration ; échantillonner les merge requests pour l’attestation du réviseur |
| 6.2.3 — Tests de sécurité dans le SDLC | SAST, SCA intégrés dans le pipeline avec portes bloquantes | Configuration du pipeline, résultats d’analyse, journaux des portes | Revoir la définition du pipeline ; échantillonner les journaux de build montrant l’exécution des analyses |
| 6.2.4 — Techniques de codage sécurisé | Application automatisée des standards de codage via linters et règles SAST | Configuration des outils, jeux de règles, journaux d’application | Revoir la configuration des règles ; vérifier l’application sur des builds échantillonnés |
| 6.3.1 — Identification des vulnérabilités | Analyse automatisée des vulnérabilités dans le pipeline de build | Configuration d’analyse, rapports de vulnérabilités | Vérifier que l’analyse s’exécute à chaque build ; revoir les rapports échantillonnés |
| 6.3.2 — Inventaire logiciel maintenu | Génération SBOM via le pipeline | Artefacts SBOM, inventaires des dépendances | Vérifier la génération SBOM ; comparer avec les composants déployés |
| 6.3.3 — Correctifs et mises à jour appliqués rapidement | Détection automatisée des mises à jour de dépendances, suivi des SLA de remédiation | Rapports de vieillissement des vulnérabilités, délais de remédiation | Échantillonner les vulnérabilités ; vérifier la remédiation dans les SLA définis |
| 6.4.1 — Détection des vulnérabilités des applications web | Intégration DAST dans le pipeline de déploiement | Configuration DAST, résultats d’analyse, enregistrements de remédiation | Vérifier l’exécution DAST ; revoir les conclusions et la remédiation |
| 6.5.1 — Procédures de contrôle des changements suivies | Gestion des changements appliquée par le pipeline avec approbation obligatoire | Journaux de déploiement avec enregistrements d’approbation | Échantillonner les déploiements ; vérifier l’approbation avant l’exécution |
| 6.5.2 — Documentation des changements complète | Éléments de travail liés, descriptions d’impact, preuves de test dans les enregistrements de déploiement | Enregistrements de changement avec documentation complète | Échantillonner les changements ; vérifier la complétude de la documentation |
| 6.5.3 — Environnement de production ségrégé | Isolation des environnements du pipeline, identifiants séparés, segmentation réseau | Schémas d’architecture, preuves de configuration | Revoir l’architecture ; vérifier les contrôles d’isolation |
| 6.5.4 — Séparation des tâches | Application par le pipeline empêchant l’auto-approbation et l’auto-déploiement | Configuration SoD, rapports de validation | Vérifier la configuration ; échantillonner les déploiements pour la conformité SoD |
| 6.5.5 — PAN réels non utilisés en test | Masquage des données par le pipeline, contrôles de données d’environnement | Procédures de gestion des données, gestion des données de test | Revoir les procédures de données de test ; vérifier l’absence de données réelles dans les environnements inférieurs |
| 6.5.6 — Données de test supprimées avant la production | Étapes de nettoyage du pipeline, vérification du déploiement en production | Procédures de déploiement, journaux de vérification de nettoyage | Revoir le processus de déploiement ; vérifier les étapes de nettoyage |
Nouvelles exigences v4.0 affectant le CI/CD
Approche personnalisée
PCI DSS v4.0 introduit l’« approche personnalisée » comme alternative à l’« approche définie » traditionnelle. Les organisations peuvent répondre à l’objectif de sécurité d’une exigence par des contrôles alternatifs, à condition de démontrer que le contrôle atteint l’objectif déclaré. Pour les environnements CI/CD, cela offre la flexibilité d’implémenter des contrôles natifs au pipeline plutôt que de rétroconcevoir des contrôles traditionnels.
Ce que cela signifie pour les responsables conformité : Si votre pipeline implémente des contrôles différemment de l’exigence prescriptive mais atteint le même objectif de sécurité, l’approche personnalisée peut être appropriée. Cependant, cela nécessite une analyse ciblée des risques pour chaque contrôle personnalisé et des preuves plus rigoureuses d’efficacité.
Analyse ciblée des risques
La v4.0 exige des analyses ciblées des risques documentées pour des exigences spécifiques où l’organisation détermine la fréquence ou le périmètre d’une activité de contrôle. Pour les pipelines CI/CD, cela inclut :
- Fréquence des analyses de vulnérabilité et des tests de pénétration
- Périmètre de la revue de code (quels changements nécessitent une revue, quel niveau de revue)
- Délais de remédiation pour les différents niveaux de gravité des vulnérabilités
- Fréquence de revue des accès pour les systèmes de pipeline
Connexion aux autres exigences
| Exigence connexe | Connexion au CI/CD | Considération clé |
|---|---|---|
| Exigence 7 (Contrôle d’accès) | L’accès au pipeline doit suivre les principes du besoin d’en connaître et du moindre privilège | RBAC sur tous les composants du pipeline ; restreindre l’accès au déploiement en production |
| Exigence 8 (Authentification) | Authentification forte pour tout accès aux systèmes du pipeline | MFA, complexité des mots de passe, gestion des identifiants de comptes de service |
| Exigence 10 (Journalisation et surveillance) | Toutes les activités du pipeline doivent être journalisées et surveillées | Pistes d’audit pour les déploiements, événements d’accès, changements de configuration ; intégrité des journaux |
| Exigence 11 (Tests de sécurité) | Tests réguliers des contrôles de sécurité du pipeline | Le périmètre des tests de pénétration inclut l’infrastructure CI/CD ; analyse des vulnérabilités des composants du pipeline |
Constats d’évaluation courants dans les environnements CI/CD
- Ségrégation incomplète des environnements : Les pipelines de développement peuvent atteindre les segments réseau de production ou utiliser des identifiants de production
- Absence de revue de code pour les changements de configuration du pipeline : Le code applicatif est revu mais les fichiers de définition du pipeline (Jenkinsfiles, configurations YAML) ne sont pas soumis à la même rigueur
- Violations des SLA de remédiation des vulnérabilités : Les vulnérabilités connues dans les dépendances restent non corrigées au-delà des délais définis
- Journalisation insuffisante des activités du pipeline : Les événements de déploiement sont journalisés mais les décisions d’approbation, les contournements de portes et les changements de configuration manquent de pistes d’audit
- Comptes de service avec un périmètre excessif : Les comptes de service du pipeline ont un accès plus large que nécessaire pour leur fonction spécifique
- Lacunes dans la gestion des données de test : Les pipelines n’appliquent pas le masquage des données et n’empêchent pas l’utilisation de données réelles de titulaires de cartes dans les environnements de test
- Absence de génération SBOM : Pas de suivi systématique des composants tiers déployés dans l’environnement de données des titulaires de cartes
Ressources connexes
Ressources connexes pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- Contrôles de sécurité CI/CD fondamentaux
- Conformité continue via CI/CD
- Architecture de double conformité
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
