Le Conseil des normes de sécurité PCI a publié la version 2.0 de la norme sur les logiciels sécurisés et le guide du programme qui l'accompagne, marquant ainsi la révision la plus importante depuis la création du cadre en 2019. Cette mise à jour remodèle fondamentalement la façon dont les logiciels de paiement sont évalués et validés, en introduisant une nouvelle terminologie, un champ d'application élargi et des processus rationalisés qui auront un impact sur les fournisseurs, les évaluateurs et les clients dans l'ensemble de l'écosystème de paiement.

Les fondements : Une nouvelle approche de l'éligibilité et du champ d'application

Le changement le plus fondamental de la v2.0 est sans doute la suppression complète du terme "logiciel de paiement" de la norme. Les critères d'éligibilité sont désormais entièrement axés sur le concept de SensitiveAssets, définicomme tout élément du produit logiciel dont l'accès, l'utilisation, la modification ou la divulgation non autorisés peuvent compromettre les fonctionnalités ou les données liées aux paiements du logiciel.

Ce recadrage conceptuel s'accompagne d'un nouveau document d'accompagnement obligatoire, SensitiveAsset Identification (SAID), qui fournit un contexte et des exemples détaillés pour l'identification des données, des fonctionnalités, des ressources et des modes de fonctionnement sensibles. Pour les données liées à l'EMVCo 3DS, la norme fait désormais référence au document PCI 3DS Data Matrix.

L'implication pratique est claire : si votre logiciel traite des actifs sensibles tels que définis par la norme, il entre dans le champ d'application, qu'il corresponde ou non aux catégories traditionnelles de logiciels de paiement.

Révision de la terminologie : Comprendre le nouveau langage

La version 2.0 introduit des mises à jour terminologiques importantes que les évaluateurs et les vendeurs doivent assimiler :

En outre, le glossaire a été déplacé d'un document SSF externe à l'annexe A de la norme elle-même, et les termes définis sont désormais indiqués dans les exigences de sécurité pour faciliter leur reconnaissance. Un nouveau terme, "Strong Authentication" (authentification forte), a été introduit, et la norme s'appuie désormais sur la base de "Strong Cryptography" (cryptographie forte) plutôt que sur des paramètres spécifiques de puissance de clé effective.

Réorganisation structurelle : Exigences fondamentales et modules

La norme v2.0 a été entièrement restructurée autour de onze objectifs de sécurité dans la section "Core", qui s'applique à tous les logiciels évalués dans le cadre :

1. Architecture, composition et versionnement des logiciels - Incluant de nouvelles exigences pour la nomenclature des matériaux et le versionnement par caractères génériques.
2. Identification des biens sensibles - Établissant les bases des exigences suivantes
3. Stockage et conservation des biens sensibles
4. SensitiveModes of Operation - Contexte formalisé pour le contrôle d'accès et l'authentification forte
5. Protection des actifs sensibles - y compris la détection formalisée des comportements anormaux
6. Sortie de biens sensibles - Avec des exigences formalisées en matière de canaux sécurisés
7. Nombres aléatoires - Exigences affinées pour l'utilisation d'un RNG externe ou la mise en œuvre interne
8. Gestion des clés
9. Cryptographie - Exigence unique englobant les domaines non couverts ailleurs.
10. Menaces et vulnérabilités
11. Déploiement et gestion sécurisés - Incluant des exigences en matière d'orientation de la mise en œuvre

Évolution du module : Ce qui a changé

Module A - Protection des données des comptes

Les exigences ont été révisées pour se concentrer uniquement sur le PAN et le SAD en relation avec PCI DSS, avec un contexte supplémentaire fourni dans le document SAID.

Module B - Logiciel du dispositif d'IOP

Rebaptisé "Exigences relatives au logiciel du terminal", ce module a été considérablement simplifié. De nombreuses exigences (B1.1, B1.2, B1.3, B3.x, B5.x) ont été absorbées dans les exigences principales, et les exigences SRED ont été révisées.

Module C - Logiciels accessibles au public

Le module a été renommé "Exigences relatives aux logiciels Web" afin de mieux rendre compte de son intention. La clarification du champ d'application est importante : ce module concerne les logiciels accessibles sur les réseaux publics, où toute personne ayant accès au réseau peut interagir avec le logiciel. Il est important de noter que les logiciels quine sont pas accessibles au public( et non ) peuvent toujours être évalués en fonction de ce module, à la discrétion du fournisseur, car les exigences contribuent à réduire les risques liés à toute mise en œuvre.

Module D - Kits de développement logiciel (NOUVEAU)

Ce module entièrement nouveau permet d'évaluer les kits de développement logiciel (SDK), y compris lesSDK EMVCo 3DS de . La norme indique explicitement que la version 2.0 remplacera à terme la norme PCI 3DS SDK, offrant ainsi aux vendeurs une plus grande flexibilité grâce à la nature plus objective de la norme Secure Software.

Changements dans le delta : Le nouveau système de niveaux

Les anciennes catégories de changement "Low Impact" et "High Impact" ont été remplacées par une structure Tier1 et Tier 2 Delta Change :

Changements Delta de niveau 1

• Changements n'ayant pas d'incidence sur la sécurité, lorsque les numéros de version doivent être modifiés mais que les caractères génériques ne sont pas utilisés.
• Avantage pour les fournisseurs qualifiés SSLC: les corrections de bogues et les correctifs ayant un impact sur la sécurité, même s'ils concernent des biens sensibles, sont considérés comme des changements de niveau 1 et peuvent être soumis sans l'intervention d'un évaluateur.

Changements dans le delta de niveau 2

• Introduction de nouveaux types d'actifs sensibles
• Changements nécessitant l'évaluation d'exigences non évaluées auparavant
• Changements impliquant ou impactant des biens sensibles (à l'exception des changements éligibles au niveau 1 pour les fournisseurs de SSLC)
• Modifications des dispositifs PTS POI
• Modification des dépendances requises
• Suppression de versions spécifiques des listes

Caractères génériques : Formalisés et réintroduits

La version des jokers a été formellement réintroduite avec des règles claires :

• Définition: Un caractère qui peut être substitué à un sous-ensemble défini de caractères possibles dans un schéma de version afin de tenir compte des changements n'ayant pas d'incidence sur la sécurité.
• Les caractères génériques ne doivent apparaître que dans la partie la plus à droite (la moins significative) des numéros de version.
• Caractères génériques autorisés : {x, y, z} en minuscules, {X, Y, Z} en majuscules ou astérisque (*).
• Un seul caractère générique représente le remplacement d'un seul chiffre {0-9}.
• Les caractères génériques ne peuvent pas représenter des modifications ayant un impact sur la sécurité.

Cette formalisation permet aux fournisseurs de gérer des versions mineures sans soumettre de changements à PCI SSC, à condition que l'utilisation des caractères génériques soit validée lors de l'évaluation complète.

Exigences de l'évaluation : Le code source est obligatoire

La version 2.0 rend explicite ce qui était auparavant implicite : la fourniture du code source est obligatoire. Le guide du programme indique sans équivoque :

"L'éditeur du logiciel est tenu de fournir le code source de son produit évalué, si l'évaluateur le juge nécessaire. Il n'est pas possible de faire évaluer un produit logiciel selon cette norme sans fournir le code source correspondant".

Les exigences de test ont été entièrement réécrites autour de trois méthodes :

1. Examen de la documentation
2. Analyse statique
3. Analyse dynamique

Cycle de vie et processus administratifs

Le cycle de validation de 3 ans reste intact :

• Années 1 et 2: Attestation annuelle du fournisseur requise
• Année 3: Réévaluation nécessaire pour maintenir la liste

Principales clarifications dans la version 2.0 :

• Période d'expiration administrative: 45 jours calendaires après la date limite d'attestation manquée, indiquée en orange sur les listes.
• Expiration du référencement: Après la période de grâce de 45 jours, les produits deviennent des produits logiciels sécurisés expirés.
• Les produits expirés doivent faire l'objet d'une nouvelle évaluation, et non d'une réévaluation, pour être réinscrits sur la liste.

Notification des problèmes de sécurité : Nouvelle section dédiée

La version 2.0 introduit unesection 8 dédiée à la notification des problèmes de sécurité, qui formalise les exigences en matière de délais de notification conformément à l'ARV :

• les exigences en matière de délais de notification conformément à l'ARV
• le format de notification requis (écrit, précédé d'un courrier électronique)
• les détails minimaux de la notification, y compris la notation CVSS
• les actions de réponse du PCI SSC, y compris le retrait potentiel de l'acceptation

Implications pratiques pour les parties prenantes

Pour les éditeurs de logiciels

• Examinez vos produits à la lumière de la nouvelle définition des actifs sensibles.
• Mettez à jour les méthodes de gestion des versions afin de tirer parti des avantages de la wildcard.
• Préparer des nomenclatures complètes pour l'évaluation
• Envisager la qualification SSLC pour les avantages du changement Delta de niveau 1
• Assurer la disponibilité du code source pour les évaluations

Pour les sociétés d'évaluation de la SSF

• Suivre la formation v2.x requise avant de procéder aux évaluations
• Se familiariser avec le nouveau document SAID
• Mettre à jour les méthodologies d'évaluation pour la nouvelle structure des exigences de test
• Se préparer aux évaluations SDK dans le cadre du module D

Pour les clients

• Vérifier que les vendeurs fournissent des conseils d'implémentation cohérents avec les numéros de version indiqués.
• Comprendre que les dépendances requises font partie de la validation - l'utilisation de dépendances non listées invalide la liste.
• Surveiller les dates d'attestation des fournisseurs et les délais de réévaluation.

Conclusion

La norme PCI Secure Software Standard v2.0 représente une maturation du cadre, passant de catégories prescriptives de logiciels de paiement à une approche basée sur des principes centrés sur la protection des actifs sensibles. L'inclusion des capacités d'évaluation des SDK, la formalisation des versions wildcard et le système de changement delta à plusieurs niveaux sont autant d'éléments qui vont dans le sens d'un programme de validation plus souple et plus durable.

Pour les organisations qui détiennent actuellement des validations v1.x ou qui prévoient de nouvelles évaluations, le moment est venu de s'engager avec des sociétés d'évaluation SSF qualifiées pour comprendre le chemin de transition et tirer parti de la flexibilité accrue qu'offre cette révision majeure.

La norme PCI Secure Software Standard v2.0 et le guide du programme v2.0 entrent en vigueur en janvier 2026. Les organisations doivent consulter la documentation officielle du PCI SSC et les évaluateurs qualifiés pour obtenir des conseils spécifiques en matière de conformité.