ASVスキャンが失敗し続ける理由：CVSSのしきい値、誤検知＆対処すべきポイント
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件でも存在すると、そのスキャン全体は無効となり、コンプライアンスの検証は不合格となります。修正対応および再スキャンが完了するまで、認証は進めることができません。
| CVSS 範囲 | 重大度 | ASV スキャン結果 |
|---|---|---|
| 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（中程度）」という表現は、対応が任意であるかのように聞こえるかもしれません。しかし、現行基準ではそうではありません。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件以上の指摘をまとめて異議申し立てする企業の傾向を認識しています。修正できるものは修正し、確実な証拠に裏付けられた真の誤検知のみを慎重に異議申し立てすべきです。
結論
「Medium」は軽視できるスコアではありません。クリーンな結果は完成報告ではありません。バージョン情報が脆弱性を意味しない場合もあります。この3点の誤解が、実際のセキュリティ問題そのものよりも多くのASVスキャン失敗の原因になっています。 これら3つのギャップは、本来検出すべき実際のセキュリティ問題よりも多くのASVスキャンサイクル失敗の原因となっています。
FAQ
PCI ASVスキャンで不合格になるCVSSスコアはいくつですか？
PCI DSS v4.0.1では、外部脆弱性スキャンにおいてCVSSスコア4.0以上の脆弱性（Mediumレベル：4.0〜6.9を含む）が存在する場合、ASVスキャンは自動的に不合格となります。コンプライアンスが有効と認められるためには、該当箇所を修正し、再スキャンを実施する必要があります。
ASVスキャンでの誤検知に対して異議申し立てを行うことはできますか？
はい。ある指摘が誤検知である場合、例えばバナーグラビングによって誤って識別されたバックポート済みパッチなどが該当します。その場合は、インストール済みパッケージのバージョン情報、ベンダーのセキュリティアドバイザリ、設定情報などの証拠をASVに提出することができます。 ASVは提出された内容を精査し、誤検知であることが確認された場合には再分類を行います。
ASVスキャンと内部脆弱性スキャンの違いは何ですか？
外部ASVスキャン（Requirement 11.3.2）は、CVSS 4.0という固定の合否基準を用い、PCI SSC認定のApproved Scanning Vendorによって実施されます。 一方、内部脆弱性スキャン（Requirement 11.3.1）は、Requirement 6.3.1に基づき組織独自のリスク評価手法に従って実施され、しきい値は社内で定義されます。
安律国際は、QSAの期待に沿ったASVレポートを通じて、企業の継続的なコンプライアンス維持を支援します。スキャンの初期仕分けから異議申し立て対応まで、プロセス全体をサポートし、7〜10営業日以内にレポートをお届けします。
ASVサービスの詳細を見る→
