ASVスキャンが失敗し続ける理由：CVSSのしきい値、誤検知 & 対処すべきポイント

ほとんどのASVスキャンの失敗は、実際の脆弱性が原因ではありません。プロセスの仕組み、しきい値の位置、出力結果の正しい解釈、そしてスキャナーが誤った情報を含むバージョン文字列を読み取ってしまう場合の影響を正しく理解していないことによって発生しています。

ASV — Approved Scanning Vendor, PCI Security Standards Council（PCI SSC）によって認定されたベンダーは、 PCI DSS 要件11.3.2で求められる外部脆弱性スキャンを実施します。コンプライアンスプログラムを失敗に導く要因の中でも、特に多い「3つの現実」が存在します。

1. CVSS 4.0のしきい値は想像よりも低い

PCI DSS v4.0.1では、外部ASVスキャンの合否判定におけるカットオフはCVSSスコア4.0と定められています。これは「Medium（中程度）」の下限にあたり、「High」や「Critical」ではありません。インターネットに公開され、かつカード会員データ環境（CDE）に接続されているホスト上で、CVSS 4.0の指摘が1件でも存在すると、そのスキャン全体は無効となり、コンプライアンスの検証は不合格となります。修正対応および再スキャンが完了するまで、認証は進めることができません。

「Medium（中程度）」という表現は、対応が任意であるかのように聞こえるかもしれません。しかし、現行基準ではそうではありません。1件でも該当すると、四半期ごとの脆弱性スキャンサイクル全体が停止してしまいます。

重要なポイントとして、この固定されたCVSS 4.0のしきい値は、外部ASVスキャン（Requirement 11.3.2）に適用されます。一方、Requirement 11.3.1に基づく内部脆弱性スキャンでは、Requirement 6.3.1で定義された自社のリスク評価手法に従って基準を設定します。 つまり、内部スキャンのしきい値は自社で定義できますが、外部ASVスキャンの基準は変更できません。

2. ASVスキャン結果がクリーンでも、QSA提出用レポートとしてそのまま通用するわけではありません

これは、私たちがFintech業界で最も多く目にするギャップの一つです。企業がスキャンツールを実行し、クリーンな結果を得たことで対応完了だと判断してしまうものの、実際には検証段階でQSAからレポート全体を差し戻されてしまうケースです。

問題は単純です。自動化されたスキャナーは生データを生成するだけであり、QSAが求めているのはコンプライアンスとして説明可能な証跡です。この2つは同じものではありません。

1回のスキャンでは数十件の指摘が返されることがあり、その多くはバナーグラビング、WAFの干渉、またはバージョン検出の誤りによる誤検知です。これらは自動的にクリーンアップされることはありません。PCI DSS v4.0.1のもとでは、ASVレポートにおいてすべての指摘事項を優先順位付けし、すべての誤検知を適切に文書化、さらにCVSS 4.0以上の脆弱性については修正するか、正式に異議申立てを行う必要があります。

コンサルタントによる精査がない場合、フィルタリングされていない指摘事項がそのままエンジニアリングチームに渡されてしまいます。その結果、チームはクロスチェックや再テストを繰り返し、最終的にはその半分がそもそも対応すべき項目ではなかったと気づくことになります。ノイズにより、数週間の工数が失われてしまいます。

3. バックポートの罠：なぜASVスキャンは誤検知を生むのか

以下は、なぜ手動による精査が重要なのかを示す最も一般的な例です。

Ubuntuホストのバナーには OpenSSH 8.2 と表示されています。スキャナーはこれを基に CVE-2023-38408 と照合し、バージョン文字列との一致から自動的に失敗としてフラグ付けします。しかし実際には、その修正はすでにディストリビューションの8.2パッケージにバックポートされており、ホスト自体はパッチ適用済みです。ただしスキャナーはその事実を認識できません。

ASVスキャンはバナーグラビングに依存しており、サービスが提示するバージョン文字列を読み取り、それをCVEデータベースと照合します。そのため、ディストリビューションがどのパッチをバックポートしているかを把握する手段がありません。 RHEL、Debian、Ubuntuはいずれもこのバックポート方式を広く採用しています。パッケージのバージョン自体は変わらない一方で、実際の脆弱性はすでに修正されている場合があります。

正しい対応は、その指摘を無視することではなく、適切に異議申し立てを行い、証拠を収集します。例えば、インストール済みパッケージのバージョン（dpkg -l や rpm -q）、バックポートを確認できるベンダーのセキュリティアドバイザリ、そして実際に適用されているパッチ済みのバージョン情報です。 それらを明確な説明とともに文書化し、ASVに提出します。

ただし、すべてを異議申し立てするべきではありません。ASVは、毎四半期30件以上の指摘をまとめて異議申し立てする企業の傾向を認識しています。修正できるものは修正し、確実な証拠に裏付けられた真の誤検知のみを慎重に異議申し立てすべきです。

FAQ