Why Your ASV Scan Keeps Failing: CVSS Thresholds, False Positives & What to Fix
Why Your ASV Scan Keeps Failing: CVSS Thresholds, False Positives & What to Fix
Most ASV scan failures aren't caused by actual vulnerabilities. They're caused by misunderstanding how the process works — where the threshold sits, what the output actually means, and what happens when a scanner reads a version string that tells the wrong story.
An ASV — Approved Scanning Vendor, certified by the PCI Security Standards Council (PCI SSC) — performs the external vulnerability scans required under PCI DSS Requirement 11.3.2. Here are the three realities that trip up compliance programs more than almost anything else.
1. The CVSS 4.0 Threshold Is Lower Than You Think
Under PCI DSS v4.0.1, the pass/fail cutoff for external ASV scans is a CVSS score of 4.0. That's the bottom of the "Medium" band — not High, not Critical. A single finding at 4.0 on an internet-facing host connected to the cardholder data environment (CDE) invalidates the entire scan and blocks compliance validation until you remediate and rescan.
| CVSS Range | Severity | ASV Scan Result |
|---|---|---|
| 0.0 – 3.9 | Low / None | Pass ✓ |
| 4.0 – 6.9 | Medium | Fail ✗ |
| 7.0 – 8.9 | High | Fail ✗ |
| 9.0 – 10.0 | Critical | Fail ✗ |
"Medium" sounds optional. Under the current standard, it isn't — it stops your quarterly vulnerability scan cycle cold.
One important distinction: this fixed CVSS 4.0 threshold applies to external ASV scans (Requirement 11.3.2). Internal vulnerability scans under Requirement 11.3.1 follow your own risk-ranking methodology defined through Requirement 6.3.1. The threshold for internal scans is yours to set. The external one is not.
2. A Clean ASV Scan Output Isn't a QSA-Ready Report
This is the gap we see most often across Fintech: a company runs a scanning tool, gets a clean output, and assumes the job is done — only to have the QSA send the entire report back during validation.
The problem is straightforward. Automated scanners produce raw data. QSAs need a defensible compliance artifact. Those are not the same thing.
A single scan can return dozens of findings — many of them false positives from banner grabbing, WAF interference, or version-detection errors. None of that gets cleaned up automatically. Under PCI DSS v4.0.1, an ASV report requires every finding to be triaged, every false positive properly documented, and every CVSS 4.0+ vulnerability either fixed or formally disputed.
Without that layer of consultant review, unfiltered findings get passed straight to engineering. Teams cross-check, retest, and eventually realize half the items shouldn't have been there in the first place. Weeks burned on noise.
3. The Backporting Trap: Why ASV Scans Flag False Positives
Here's the most common example of why manual review matters.
Your Ubuntu host shows OpenSSH 8.2 in its banner. The scanner cross-references CVE-2023-38408, finds a match against that version string, and flags an automatic failure. Except that fix was backported into the distro's 8.2 package months ago. The host is patched. The scanner doesn't know that.
ASV scans rely on banner grabbing — they read the version string a service advertises and check it against a CVE database. They have no way of knowing which patches your distribution backported silently. RHEL, Debian, and Ubuntu all do this heavily. The package version doesn't change, but the underlying vulnerability is fixed.
The right response isn't to ignore the finding — it's to dispute it properly. Gather evidence: installed package versions (dpkg -l, rpm -q), the vendor security advisory confirming the backport, and your actual patched version string. Submit it in writing to your ASV with a clear description.
But don't dispute everything. ASVs notice when companies contest 30+ findings every quarter. Fix what you can. Dispute only the genuine false positives backed by clean evidence.
The Bottom Line
A "Medium" score isn't optional. A clean scan output isn't a finished report. A "vulnerable" version string isn't always a vulnerability. These three gaps account for more failed ASV scan cycles than the actual security issues they're designed to catch.
Frequently Asked Questions
What CVSS score fails a PCI ASV scan?
Under PCI DSS v4.0.1, any external vulnerability with a CVSS score of 4.0 or higher — including Medium severity (4.0–6.9) — automatically fails the ASV scan. The scan must be remediated and rescanned before compliance can be validated.
Can I dispute false positives on an ASV scan?
Yes. If a finding is a false positive — for example, a backported patch that the scanner misidentified via banner grabbing — you can submit evidence to your ASV including installed package versions, vendor security advisories, and configuration documentation. The ASV reviews and reclassifies confirmed false positives.
What is the difference between an ASV scan and an internal vulnerability scan?
External ASV scans (Requirement 11.3.2) use a fixed CVSS 4.0 pass/fail threshold and must be performed by a PCI SSC-approved Approved Scanning Vendor. Internal vulnerability scans (Requirement 11.3.1) follow the organization's own risk-ranking methodology defined under Requirement 6.3.1, with thresholds set internally.
At Secure Vectors, we help businesses stay continuously compliant with ASV reports aligned to QSA expectations — delivered in 7–10 business days, with full scan lifecycle support from triage through dispute resolution.
Learn More About Our ASV Service →
