基礎知識
·
May 21, 2026

ASVスキャンが繰り返し失敗する理由:CVSSしきい値、誤検知、そして修正すべきポイント

ASVスキャンの失敗の多くは、実際の脆弱性が原因ではありません。CVSS 4.0のしきい値、QSA対応レポート、そしてバックポートの落とし穴について解説します。

Article cover image

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)に接続されたインターネット公開ホスト上で4.0の指摘が1件でも検出されれば、スキャン全体が無効となり、是正対応と再スキャンを行うまで準拠の検証が滞ります。

PCI ASVスキャン — CVSS合否基準:

  • 0.0 – 3.9(Low/None): 合格 ✓
  • 4.0 – 6.9(Medium): 不合格 ✗
  • 7.0 – 8.9(High): 不合格 ✗
  • 9.0 – 10.0(Critical): 不合格 ✗

「Medium」と聞くと任意対応のように思われがちです。しかし現行の基準においてはそうではなく、四半期ごとの脆弱性スキャンのサイクルを完全に停止させてしまいます。

重要な区別が1つあります。この固定されたCVSS 4.0のしきい値が適用されるのは外部ASVスキャン(要件11.3.2)です。要件11.3.1に基づく内部脆弱性スキャンは、要件6.3.1を通じて定義した自組織のリスクランク付け手法に従います。内部スキャンのしきい値は自社で設定できますが、外部スキャンのしきい値は設定できません。

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 -lrpm -q)、バックポートを裏付けるベンダーのセキュリティアドバイザリ、実際に適用済みのバージョン文字列といった証跡を収集してください。そのうえで、明確な説明を添えて書面でASVへ提出します。

ただし、何でも異議申立てを行うべきではありません。ASVは、毎四半期30件以上の指摘に異議を唱える企業に気づきます。修正できるものは修正してください。異議申立ては、明確な証跡に裏付けられた真の誤検知に限定すべきです。

まとめ

「Medium」のスコアは任意対応ではありません。クリーンなスキャン出力は完成したレポートではありません。「脆弱」とされたバージョン文字列が、必ずしも脆弱性を意味するわけではありません。これら3つの乖離は、ASVスキャンが本来検出しようとしている実際のセキュリティ上の問題よりも多くの失敗サイクルを生み出しています。

よくあるご質問

PCI ASVスキャンで不合格となるCVSSスコアはどれくらいですか。

PCI DSS v4.0.1では、CVSSスコア4.0以上の外部脆弱性は、Medium(中)レベル(4.0〜6.9)を含めて自動的にASVスキャン不合格となります。準拠を検証するには、是正対応を行ったうえで再スキャンを実施する必要があります。

ASVスキャンの誤検知に対して異議申立てはできますか。

はい、可能です。指摘が誤検知である場合、たとえばバックポートされたパッチをスキャナーがバナーグラビングにより誤認識した場合などには、インストール済みパッケージのバージョン、ベンダーのセキュリティアドバイザリ、設定に関する文書などの証跡をASVへ提出できます。ASVはこれを審査し、誤検知と確認されたものを再分類します。

ASVスキャンと内部脆弱性スキャンの違いは何ですか。

外部ASVスキャン(要件11.3.2)は、CVSS 4.0という固定の合否しきい値を用い、PCI SSCの認定を受けたASV(Approved Scanning Vendor)が行う必要があります。内部脆弱性スキャン(要件11.3.1)は、要件6.3.1に基づき組織が独自に定めたリスクランク付け手法に従い、しきい値は社内で設定します。

安律国際では、QSAの期待水準に沿ったASVレポートにより、企業が継続的に準拠状態を維持できるよう支援しています。7〜10営業日で納品し、トリアージから異議申立ての解決まで、スキャンのライフサイクル全体をサポートいたします。

ASVサービスの詳細はこちら →

PCI準拠に関するご相談は、今すぐ専門家へお問い合わせください

👉 お問い合わせ