PCI DSS SAQ A qualification - what counts as a 'found' vulnerability?

Question

This Q pertains to PCI DSS v4.0 SAQ A - previous Q&A only touched on previous versions of PCI.

Since 4.0, merchants that accept credit card payment, even if they only iframe or link to their payment provider and the rest is done on the provider's site, have to have an approved security vendor (ASV) scan their own site every three months, and fix any found vulnerabilities.

We want to prepare for our first scan - we are using opencart v4.0.2.3, which has, amongst others, this 'vulnerability': CVE-2024-21518 (CVSS v3.1: 7.2)

A scan will trivially find our opencart version, and (I'm guessing at the functionality of the scanning script) thus the CVE. The CVE is not pertaining to DDoS (in which case it could be ignored for PCI DSS), and there is no fix. It also only pertains to a zip-slip-path-traversal, if the file is uploaded by an (XSS-duped) admin. Our admin area is IP-restricted, and the access happens via VPN, so this is not something that is terribly relevant for us. It is a current CVE rated higher than 3.9 and we cannot fix it, though, so per PCI DSS we would fail ... IF something like this cropping up on the scan counts as a 'found vulnerability'. Does it? Or is the scan structured so only CVE that are truly exploitable in the actual setup count as 'found'?

Anybody had their shop SAQ-A-PCI-ASV scanned, failed (virtual certainty, as there is virtually no modern stack that is fully fixed at all times) and then... did what? pls speak up, there have to be thousands

(The pricing of the scan indicates that this will entail barely more than someone aiming some script at our provided IP, and mailing the autogenerated report, so I do not expect much human intervention along the lines of 'Oh this CVE is actually not a thing if used with that kind of setup', after the fact)

Answer 1

A scan will trivially find our opencart version, and (I'm guessing at the functionality of the scanning script) thus the CVE.

In which case the CVE will be reported as a vulnerability found on the scan - with ASV scanning there is generally no manual review or attempt to confirm the actual existence of vulnerabilities beyond version detection. It's essentially someone running Nessus/Qualys/etc with a pre-defined profile and exporting it into a pre-formatted report

It is a current CVE rated higher than 3.9 and we cannot fix it, though, so per PCI DSS we would fail

If there is a legitimate issue (i.e, it's not a false positive) then your first step should be getting OpenCart to fix it - but that doesn't help you in the short term.

But there is still a way that you can pass the ASV scanning using compensating controls. From the ASV Program Guide

Addressing Vulnerabilities with Compensating Controls The customer may dispute the results of an ASV scan by stating they have compensating controls in place to reduce or eliminate the risk of a vulnerability identified in the scanning report. In this case, the following is required:

• The ASV must assess the relevance and accuracy of the compensating controls to meet the risk presented by the vulnerability.
• The ASV’s conclusion should be documented in the scanning report under ―Exceptions, False Positives, or Compensating Controls as noted in Appendix B: ASV Scan Report Executive Summary.
• The customer must not be permitted to edit the scanning report.
• The ASV scan must not reduce the search space of any scan by discarding vulnerabilities met by compensating controls.

So when the ASV scan comes back with that vulnerability, you need to provide them with evidence of the compensating controls that you have in place, and convince them that those controls are adequate to prevent exploitation (or at least to reduce the risk down to an acceptable level). Exactly what those are will depend on the specifics of the vulnerability and your environment.