脆弱性スキャナーで結果が食い違う理由｜査読前研究を解説

研究・論文

同じソフトウェアを調べているのに、使う脆弱性スキャナーによって検出結果が食い違う——多くの情シス担当者が一度は経験する「あるある」です。2026年7月に公開された査読前論文「The Distributed Open-Source Vulnerability Ecosystem」（Peter Mandl・Paul Mandl）は、この食い違いが単なるツールのバグではなく、オープンソースの脆弱性情報が分散して流通・変換される仕組みそのものから生まれる構造的な現象だと整理しています。本記事はその要点を、実務者向けに噛み砕いて解説します。

【ご注意】本記事が基にしているのは査読前（プレプリント）の研究です。査読を経ていないため、結論や解釈は今後変わりうる点にご留意ください。以下では、公開されている一次情報（NIST/NVD等）で裏付けが取れる部分を中心に補足しています。

この記事でわかること

  • なぜスキャナーごとに脆弱性の検出結果が違うのか（4つの原因）
  • NVDの処理遅延やCPE欠落など、いま実際に起きていること
  • 「どのツールが正しいか」ではなく、情シスとしてどう向き合うか

この研究は何を示したのか？

脆弱性管理を「1つの中央データベース」ではなく、情報が段階的に受け渡され変換されていく「分散プロセス」として捉え直した点が核心です。脆弱性情報は、発見・標準化 → 各データベースでの補強（エンリッチメント） → 利用者の環境に合わせた解釈、という段階を経ます。著者らは、この各段階で情報が少しずつ形を変えるため、下流にいるスキャナー同士の結果がずれるのは自然な帰結だと論じています。

公開されている脆弱性情報は共通の標準（CVE・CVSSなど）に基づいているにもかかわらず、同じソフトウェア構成に対して異なるスキャナーが矛盾した結果を返す。この一見不思議な現象を、エコシステムの構造から説明したのが本研究です。

なぜスキャナーで結果が食い違うのか？

論文は、食い違いの主因を大きく4つに整理しています。いずれも「どれかが壊れている」のではなく、情報源と突き合わせ方の違いから生じます。

原因 内容 現場で起きること
異なる情報源 NVD、OSV、GitHub Advisory、各Linuxディストリビューション等、参照するDBが複数ある ツールAは検出、ツールBは未検出、という差が出る
識別・バージョンモデルの違い 製品やバージョンの表し方（CPEとPURLなど）が統一されていない 同じパッケージでも「該当/非該当」の判定がずれる
時間的な変化 脆弱性情報は後から追記・修正（遡及的な更新）される スキャンした日によって結果が変わる
文脈依存の解釈 「実際に到達可能か」「利用中か」など環境ごとの評価が入る 同じCVEでも深刻度・要否の判断が分かれる

とくに識別モデルの違いは根が深い部分です。従来のNVDはCPE（Common Platform Enumeration）という識別子で製品を突き合わせますが、パッケージ管理の世界ではPURL（Package URL）が使われることも多く、両者の対応は完全ではありません。突き合わせの「物差し」が違えば、同じ在庫でも結果が変わるのは当然といえます。

いま現実に何が起きているのか？

この研究の指摘は、2024年以降のNVDを取り巻く現実と重なります。CVEの登録数は2020年から2025年にかけて263%増加し、NVDの補強作業が追いつかなくなりました。2025年3月時点で未処理のCVEは約25,000件に達したと報じられています。

そしてNIST（米国立標準技術研究所）は2026年4月、方針転換を発表しました。約29,000件の滞留CVEを「Not Scheduled（予定なし）」に分類し直し、今後フル補強の対象をCISAの悪用実績カタログ（KEV）掲載分・連邦政府ソフトウェア・重要ソフトウェアなど、全体の15〜20%程度に絞るというものです。

スキャナーへの影響として深刻なのがCPEデータの欠落です。2024年に公開されたCVEのうちCPEが付いているのは約41%にとどまるとされ、裏を返せば約6割のCVEはスキャナーが突き合わせるためのCPEを持たない。CPEのないCVEは、多くのスキャナーから見れば「存在しない」も同然です。CVSSスコアについても、CNA（採番機関）とNISTの評価が食い違う例が半数超あるとの指摘があり、どの値を採用するかで優先度が変わります。論文が言う「情報源の異質さ」「時間的変化」は、まさにこの現実として表れているわけです。

情シスはどう向き合うべきか？

結論は「1つのスキャナーの出力を絶対の真実として扱わない」ことです。ツール同士の食い違いは異常ではなく仕様に近い、と理解したうえで運用を組むのが現実的です。実務で意識したい点を挙げます。

  • 単一ツールに依存しない：可能なら複数の情報源（NVDに加えOSVやベンダー公式、CISA KEV）を突き合わせ、差分の理由を確認する。
  • 「検出ゼロ＝安全」と読み替えない：CPE欠落などで単に拾えていないだけの可能性がある。
  • 優先度は悪用実績で絞る：件数の多さに圧倒されないよう、KEV掲載など「実際に悪用されている」情報を軸にトリアージする。
  • スキャン結果は日付とツール名込みで記録する：後から結果が変わる前提で、いつ・何で調べたかを残す。

正直なところ、限られた人員で毎日数万件規模のCVEを追い、ツールごとの差分まで一つずつ検証するのは現実的ではありません。「ツールAは20件、ツールBは35件、どちらが正しいのか」と問われても即答できないもどかしさは、多くの現場が抱えているはずです。だからこそ、全件をつぶすのではなく悪用実績と自社への影響で優先度を割り切る割り切りが要になります。脆弱性管理の考え方の土台は、IPAの公的資料で押さえておくのが確実です。まずは中小企業の情報セキュリティ対策ガイドラインで自組織の運用レベルを点検し、社内の資産管理・パッチ運用のルールと突き合わせておきましょう。

前提として、脆弱性がどこから入り込むのかを理解しておくことも大切です。ソフトウェア部品の供給網を狙う攻撃の全体像はサプライチェーン攻撃とは？仕組みと種類で、AI領域での具体例はLLMサプライチェーンの脆弱性529件の分析で解説しています。悪用実績（KEV）を軸にした優先度付けの実例はOracle EBS脆弱性のKEV追加の記事も参考になります。

この研究の限界・留意点

繰り返しになりますが、本論文は査読前のプレプリントです。エコシステムを「分散プロセス」として概念的に整理した論考であり、特定のスキャナー製品の優劣を評価したものではありません。ここで示された4つの原因も、今後の査読や追試で表現や重み付けが変わる可能性があります。個別の製品選定や対策の最終判断は、必ず各ベンダーの公式情報とIPA/JPCERT/CC等の一次情報を確認したうえで行ってください。

まとめ

  • 脆弱性スキャナーの結果の食い違いは、情報が分散して流通・変換されるエコシステムの構造から生じる（査読前研究の指摘）。
  • 主因は「情報源の違い」「識別・バージョンモデルの違い（CPE対PURL）」「時間的変化」「文脈依存の解釈」の4つ。NVDの処理遅延やCPE欠落として現実にも表れている。
  • 情シスは単一ツールの出力を絶対視せず、複数情報源の突き合わせと、悪用実績（KEV）を軸にした優先度付けで割り切ることが現実的。

出典

タイトルとURLをコピーしました