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.

"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.

Frequently Asked Questions