脆弱性ブログタイトル画像

なぜ脆弱性は「過剰検知」されるのか?
―AI時代の脆弱性管理とトリアージ

「脆弱性診断はきちんとやっているが、脆弱性対応がまったく終わらない」 どの現場でも抱える問題です。
背景には、ClaudeをはじめとするフロンティアAIモデルの進化があります。
AIが大量の脆弱性を発見するため、CVE(共通脆弱性識別子)として登録される件数は、今後、加速度的に増加します。
「脆弱性が増え続ける→診断すればするほど脆弱性が積み上がる→対応が終わらない」という悪循環に、多くの情報システム部門・セキュリティ担当者が頭を抱えているのではないでしょうか。

何年も前から積もっていた問題が、AIにより臨界点を超えた

CVE(脆弱性の識別子)の登録件数を振り返ると、2000年に発見された脆弱性は約1,000件でした。それが2023年には約2.6万件と、20倍以上のペースです。
2026年は、AIによる大量の脆弱性発見も拍車をかけ、6.6万件以上のCVE数が予測されています。
元々、脆弱性の"洪水"は今に始まった話ではなく、この20年間、進行していた問題です。
それがAIにより、脆弱性が急増したことで、現場対応は限界を迎えつつあります。

なぜ脆弱性は「過剰検知」されるのか

ここで一つ、重要な数字を紹介します。

毎年新たに登録されるCVEの半分以上は、深刻度が「緊急(Critical)」または「重要(High)」に分類されます。
しかし、実際に悪用が確認されている脆弱性は、全体のわずか5%程度しかありません
(Tenable、Kenna Securityなどの調査より)。

「深刻度が高い」とラベル付けされた脆弱性の大部分は、実際には使われていない可能性が高いのです。
このギャップはなぜ生まれるのか。技術の話だけでは説明できない、複数の要因があります。

1.報告する側のインセンティブ

脆弱性を発見・報告する研究者やバグハンターの中には、自身の実績づくりや報酬アップのために、深刻度を高めに報告する動機があります。
実際には、誠実な研究者・バグハンターが多いのですが、過剰に宣伝した方が利益になるという、構造(インセンティブ)の問題があります。

2.「検知数を増やす」方向に働く競争原理

セキュリティ製品・スキャナーの間では、「見逃し(偽陰性)を減らす」ことが製品の信頼性に直結します。
その結果、各ベンダーは検知の閾値を「疑わしきは検知する」側に設定する傾向があり、これが偽陽性(過剰検知)を増やす要因になっています。

3.CVSSは「リスク」そのものではない

多くのツールが参照するCVSS(共通脆弱性評価システム)は、あくまで「技術的な深刻度」を測る指標です。しかし実際のリスクは、

リスク = 脅威 × 脆弱性 × 情報資産

という式で決まります。同じ脆弱性でも、外部から到達できない環境にあるか、重要な情報資産を扱っていないかによって、実際のリスクは大きく変わります。

4.CVSSは脆弱性自体の評価であり、アプリの評価ではない

さらに、脆弱性の悪用度は、そのアプリ・サーバーの文脈によって決まります。
あるライブラリに深刻な脆弱性があったとしても、「その前段階で入力がサニタイジング(攻撃的な文字列を無効化する)されている」「そもそも対象機能がオフになっている」ことも珍しくはありません。

精度99%のスキャナーでも「本当に脆弱性がある確率」は9%

過剰検知の構造を、直感的に理解する思考実験があります。

Q. あるサーバー製品では、1,000台に1台の割合で脆弱性Xが存在します。精度99%の診断ツールで対象サーバーをスキャンしたところ、脆弱性Xが検出されました。このとき、対象サーバーが本当に脆弱性Xを抱えている確率は何%でしょうか?

「精度99%なのだから、99%くらいだろう」と思うかもしれません。しかし、ベイズの定理で計算すると、答えは大きく変わります。

  • 脆弱性Xが実際に存在する確率:0.001
  • 脆弱性Xが存在するときに検出される確率:0.001 × 0.99
  • 脆弱性Xが検出される確率(全体):0.001 × 0.99 + 0.999 × 0.01
  • このとき、検出された際に本当に脆弱性Xが存在する確率は、
    (0.001 × 0.99) / (0.001 × 0.99 + 0.999 × 0.01)
    ≒ 0.009... = 約9%

精度99%という優秀なツールを使っても、「1,000台に1台」程度の頻度でしか存在しない脆弱性であれば、検知結果が「本物」である確率はわずか9%しかありません。
統計学ではこれを「基準率の誤謬」と呼びます。
勿論、実際の脆弱性診断はこのような確率論で表せるものでは無いですが、
「検査結果を鵜呑みにしてはいけない」好例として、検査現場で使われることがあります。

じゃあ、どうすればいいのか

ここまでの話を整理すると、

  • 脆弱性は増え続けている(そしてAIによりさらに増える)
  • ツールが「Critical」と検知しても、実際に危険なのはごく一部
  • とはいえ「今わかっている脆弱性」への対応こそが最も重要


そのため、『実態に即して優先順位を付け続ける(トリアージ)』がよく用いられています。

しかし、多くの現場では、この脆弱性のトリアージが手動やExcel管理で行われているため、近年の脆弱性の急増・対象規模の増加によって、その人手のトリアージ作業すらも限界を迎えています。

そこで近年広がっているのが、脆弱性管理(VM: Vulnerability Management)という考え方です。

VMツールは、単発の診断結果を溜め込むだけの仕組みとは異なり、

  • スキャンで得られた資産情報(OS・ミドルウェア・バージョン等)と、検出した脆弱性を継続的に統合管理する
  • 脆弱性単位で「どのサーバー群が対象か」を横断的に検索できる
  • 対応状況の変化を、時系列で追い続けられる


といった特徴を持ちます。

エクサも実際にTenable VMの導入を提案・支援してきましたが、現場でよく感じるのは、「ツールを入れただけ」では結局振り出しに戻ってしまうということです。
VMを繋いだ直後は、依然としてCritical(緊急脆弱性)の件数に圧倒されるケースが少なくありません。
そこから一段進むには、自社の環境を踏まえてリスクレベルを補正し続ける運用──つまり、「ツールと人の判断を組み合わせる仕組み」が伴ってはじめて、VM導入の効果が現れてきます。

エクサの脆弱性管理(Tenable VM)導入・支援サービスを詳しく知りたいという方は、ぜひ以下の記事もご覧ください。

AIは「敵」にも「味方」にもなる

最後に、少し先の話をします。

AIが脆弱性の発見を加速させることは、当面は「対応すべき数が増える」というマイナス面が目立ちます。しかし、AIには「過剰検知を減らす」側の可能性も確実に存在します。

2020年に発表されたオックスフォード大学の研究では、CVE情報・エクスプロイトコード・実際のトラフィックデータなど、脆弱性に関するあらゆるデータを学習させた機械学習モデルが、実際に悪用される脆弱性の94.5%を的中させることに成功しました。
全CVEのうち実際に悪用されるのは約5%という前提を踏まえると、驚異的な精度です。

このモデルの学習データには、数百社の実際の脆弱性対応記録や、数十億規模の実トラフィックデータといった、非公開の"実運用データ"が多く含まれていました。つまり精度向上の鍵は、「実際の現場で何が起きたか」というデータの量にあります。

ここで、脆弱性管理SaaSの存在が重要になってきます。世界中の企業が日々「この脆弱性は自社では低リスクだからLowに修正しよう」「これは偽陽性だからignoreにしよう」と判断し続けることで、SaaSには膨大な"実運用の判断データ"が蓄積されていきます。
将来、このデータを学習した高精度なAIモデルが生まれれば、脆弱性管理はさらに一歩進んだ形へと進化することが期待されます。

フロンティアAIが脆弱性の"発見"を加速させる一方で、脆弱性管理の現場に蓄積されるデータが"優先順位付け(トリアージ)"を担うAIを育てていく──この両輪こそが、これからの脆弱性対応の姿ではないでしょうか。

おわりに

脆弱性は増え続けており、AIの進化がそのペースをさらに引き上げようとしています。しかし、検知された脆弱性の多くが「過剰検知」であることも、また事実です。大切なのは、闇雲に対応数を追うのではなく、実態に即して優先順位をつけ、継続的に見直していく仕組みを持つことです。

出典・参考文献

1.

Qualys「2023 Threat Landscape Year in Review」(2023)
blog.qualys.com
CVE増加傾向(2000年:約1,000件→2023年:約2.6万件)の出典。

2.

2026年は66,000件のCVE数を予測(2026)
first.org/newsroom

3.

Tenable Research「You Can't Fix Everything」(2022) / Kenna Security Report (2019)
jp.tenable.com / informationsecuritybuzz.com
CVEの半分以上がCritical/Highだが、実際に悪用されるのは3〜5%程度、という数字の出典。

4.

BleepingComputer「Dev rejects CVE severity, makes his GitHub repo read-only」(2024)
bleepingcomputer.com

5.

Carnegie Mellon University, Software Engineering Institute「Towards Improving CVSS」(2018)
sei.cmu.edu
CVSSは技術的深刻度の指標であり、リスクそのものではない、という論点の出典。

6.

スチュワート、小林(訳)『情報セキュリティの敗北史』(2022) 4章

7.

Jacobs, J., Romanosky, S., Adjerid, I., & Baker, W. (2020). "Improving vulnerability remediation through better exploit prediction." Journal of Cybersecurity.
first.org/epss
本研究の考え方は、現在FIRST.orgの業界標準指標「EPSS」として実用化されている。

関連する記事

関連ソリューション

関連事例

お問い合わせ

CONTACT

Webからのお問い合わせ
エクサの最新情報と
セミナー案内を
お届けします