Requirement 6 Secure Dev PCI-DSS
conformiteDéfinition
L'exigence 6 de PCI-DSS (Develop and Maintain Secure Systems and Software) traite de la sécurité dans le cycle de développement des systèmes et des logiciels utilisés dans le Cardholder Data Environment (CDE). Cette exigence vise à s'assurer que les vulnérabilités de sécurité ne sont pas introduites dans les applications et systèmes de paiement par des pratiques de développement insuffisantes. PCI-DSS v4.0 restructure l'exigence 6 en deux grandes parties : la gestion des vulnérabilités dans les composants système (6.1 à 6.3) et la sécurité des systèmes accessibles depuis le web (6.4). La gestion des vulnérabilités couvre les processus d'identification et de correction des vulnérabilités dans les systèmes et logiciels du CDE, avec des délais définis pour les correctifs selon la criticité (critique : un mois, risque élevé : trois mois). La sécurité du développement logiciel (exigences 6.2 et 6.3) impose : une formation des développeurs aux pratiques de développement sécurisé, la revue de code pour toutes les modifications du code interne avant déploiement en production (par un développeur autre que l'auteur), et un processus de gestion des changements incluant des tests de sécurité. Pour les environnements de développement/test, les données de production CHD ne doivent jamais être utilisées. Les exigences 6.4.1 et 6.4.2 (nouvelles dans v4.0, applicables depuis mars 2025) ciblent spécifiquement les pages de paiement web : inventaire de tous les scripts chargés sur la page, méthode pour confirmer l'autorisation de chaque script, mécanisme pour alerter sur les modifications non autorisées des scripts (protection anti-Magecart), et politique de sécurité du contenu (CSP). Ces exigences répondent aux attaques de type e-skimming ayant compromis des milliers de sites e-commerce. Pour les applications web en production, un WAF (Web Application Firewall) ou une revue de code sécurisée conforme à OWASP ou équivalent est requis pour protéger contre les attaques web courantes (injection SQL, XSS, CSRF, SSRF).
Gestion des vulnérabilités et correctifs
L'exigence 6.3 de PCI-DSS v4.0 impose un programme de gestion des vulnérabilités : identification des vulnérabilités via des sources fiables (NVD, bulletins éditeurs, threat intelligence), classification par criticité, et correction dans des délais définis : critiques (CVSS ≥9.0) en un mois, élevées (CVSS 7.0-8.9) en un mois, moyennes en trois mois. Pour les vulnérabilités ne pouvant pas être corrigées immédiatement, des contrôles compensatoires doivent être documentés.
Les logiciels tiers et open source dans le CDE sont également concernés : l'organisation doit maintenir un inventaire des composants logiciels (équivalent à une SBOM) et surveiller les avis de sécurité pour chaque composant. La compromission de composants open source (ex. : Log4Shell) a illustré l'importance de cette surveillance.
Développement sécurisé et revue de code
L'exigence 6.2 impose que toutes les modifications du code interne des applications dans le CDE fassent l'objet d'une revue de code par un développeur qualifié autre que l'auteur, avant déploiement en production. Cette revue couvre : les vulnérabilités OWASP Top 10, les validations d'entrée, la gestion des erreurs, la gestion des sessions, et la protection contre les injections.
Les développeurs exposés aux environnements PCI-DSS doivent recevoir une formation annuelle sur les pratiques de développement sécurisé, couvrant les risques spécifiques à leur technologie (Java, PHP, Python, JavaScript, etc.) et les vulnérabilités courantes des applications de paiement. Cette formation doit être documentée.
Protection des pages de paiement (v4.0)
Les exigences 6.4.1 et 6.4.2, applicables depuis mars 2025, imposent pour les marchands e-commerce ayant des pages de paiement : un inventaire exhaustif de tous les scripts chargés sur les pages de paiement, une justification documentée pour chaque script, un mécanisme de détection des modifications non autorisées (intégrité des scripts via CSP, SRI - Subresource Integrity, ou monitoring en temps réel), et des alertes automatiques sur toute modification.
La mise en conformité passe par : audit de tous les scripts tiers sur les pages de paiement (GTM, analytics, chat, widgets sociaux), décision de maintenir ou supprimer chaque script (minimalisme des scripts), implémentation d'une Content Security Policy (CSP) restrictive spécifiant les sources autorisées, et mise en place d'un système de monitoring de l'intégrité des scripts (services comme Featurespace, PerimeterX, ou outils maison).
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.