Un Approved Scanning Vendor (ASV) est une entreprise certifiée par le PCI Security Standards Council pour réaliser les scans externes de vulnérabilités que PCI DSS exige au moins chaque trimestre. Les scans ASV sondent vos systèmes exposés à internet à la recherche de vulnérabilités connues depuis l'extérieur, et le rapport réussi fait partie des preuves de conformité que les marchands soumettent avec leur SAQ ou Report on Compliance.
Que vérifie réellement un scan ASV ?
Un scan ASV s'exécute depuis l'infrastructure du fournisseur contre votre empreinte publique : serveurs web, services exposés, configurations TLS, versions logicielles vulnérables connues et erreurs de configuration courantes. Le fournisseur opère selon l'ASV Program Guide du Council, qui standardise la notation — les vulnérabilités notées CVSS 4.0 ou plus font généralement échouer le scan — et impose que l'ASV atteste les résultats.
Sous PCI DSS 4.0.1, l'exigence 11.3.2 impose ces scans au moins une fois tous les trois mois et après tout changement significatif. En cas d'échec, vous remédiez et rescannez jusqu'à réussir.
Scan ASV vs scan interne vs test d'intrusion
| Scan ASV | Scan interne de vulnérabilités | Test d'intrusion | |
|---|---|---|---|
| Qui l'exécute | Fournisseur certifié PCI SSC | Votre équipe ou tout outil qualifié | Testeurs qualifiés (internes ou externes) |
| Point de vue | Extérieur, exposé à internet | Intérieur du réseau | L'un ou l'autre, orienté objectif |
| Méthode | Scan automatisé | Scan automatisé | Exploitation manuelle |
| Exigence PCI | 11.3.2, trimestriel | 11.3.1, trimestriel | 11.4, au moins annuel |
| Livrable | Rapport attesté réussite/échec | Constats hiérarchisés à remédier | Rapport narratif des chemins exploités |
Les trois sont des contrôles au niveau réseau et systèmes. Aucun n'exécute votre site web comme le fait le navigateur d'un client.
Ce qu'un scan ASV ne peut pas voir
Un scan ASV ne rend jamais votre page de paiement. Il ne peut pas observer le JavaScript qui s'exécute réellement dans le navigateur d'un client — précisément là où se produit l'e-skimming. Un script Magecart injecté via un tiers compromis réussit tous les scans trimestriels, car du point de vue de la bordure réseau, rien n'a changé sur vos serveurs.
Cet angle mort est la raison pour laquelle PCI DSS 4.0.1 a ajouté deux exigences au niveau du navigateur : le 6.4.3, un inventaire autorisé de chaque script des pages de paiement avec justification métier, et le 11.6.1, la détection de manipulation des en-têtes et du contenu des scripts reçus par le navigateur du consommateur. Ces exigences demandent des preuves issues de sessions réelles, pas de sondes réseau — ce que produit le PCI Shield de cside, dans le format que les QSA acceptent réellement.
Comment les pièces s'assemblent
Voyez le scan ASV trimestriel comme l'hygiène du périmètre, le test d'intrusion comme un exercice adversarial, et le 6.4.3/11.6.1 comme la protection à l'exécution de la page de paiement elle-même. Une posture PCI DSS 4.0.1 complète a besoin des trois couches, et le coût de chacune évolue différemment : le scan ASV est banalisé et bon marché ; les preuves au niveau du navigateur sont l'endroit où les marchands découvrent le plus souvent une lacune lors de leur première évaluation 4.0.1.
