脆弱性の優先度は組織で変わる｜査読前研究を解説

脆弱性の優先度は組織で変わる｜査読前研究を解説 研究・論文

【更新 2026-08-24】本記事を見直し、修正しました。主な修正点：比較対象「Industrial Signals」を「固定基準で動く」と説明していた箇所を、原論文の記述（CVSS・EPSS相当・KEV相当などを特徴量として学習するランカー）に合わせて修正。あわせて比較表の注記を「外部手法で最良」に改めました。

脆弱性対応の優先順位は、同じCVEでも組織によって変わります。「悪用が確認されたものから潰す」のか、「パッチが出ているものから片付ける」のか。どちらも正しく、どちらを取るかは組織の事情次第です。

2026年8月19日（協定世界時）にarXivで公開された査読前論文「HARP」は、この組織ごとの判断基準を文章で書き出さずに、過去の判断事例から学習して脆弱性を並べ替える手法を提案しました。CVSS・EPSS相当・KEV相当のシグナルを組み合わせたベースラインが上位適合率0.4966だったのに対し、HARPは0.8404を記録しています。

ただし、この数字はそのまま「AIに任せれば精度が4割上がる」という話ではありません。正解データの作り方まで含めて読む必要があります。

この記事でわかること

  • HARPが何を解こうとしているのか（＝優先度の基準は言語化しにくい、という前提）
  • 知識グラフ・3つの視点・過去事例という仕組みの骨子
  • 報告された数字と、その数字を鵜呑みにしない読み方
  • 情シスの脆弱性トリアージ運用に、いま何を持ち帰れるか

どんな研究か（1文でいうと）

HARPとは、自然文の問い合わせと「過去に自組織で下した優先度判断の事例」を手がかりに、CVEの候補群を並べ替えるフレームワークです。判断基準そのものをプロンプトに書き下す必要がない点が特徴です。

項目 内容
論文タイトル HARP: Hierarchical Adaptive Ranking with Preference-Adaptive Fusion for Query-Based CVE Prioritization
著者 Haochen Liu、Zhengzhang Chen、Haoyu Wang、Yanchi Liu、Jundong Li、Haifeng Chen
所属 University of Virginia / NEC Laboratories America
公開 arXiv:2608.19430v1（2026年8月19日・協定世界時）
分類 cs.IR（主）／cs.CL／cs.CR
査読状況 査読前（プレプリント）。投稿先・採録先の記載なし

前提：優先度の基準は「言語化しにくい」

論文が出発点に置いているのは、実務者なら心当たりのある事実です。組織はすでに何らかの優先度の付け方で動いているが、その基準は暗黙的で、指示文として書き出すのが難しい。そして日々のトリアージの問い合わせ（「今週これらのうちどれから手を付けるか」）には、その基準は書かれていない。

一方で、過去に自組織が下した判断の記録は比較的手に入りやすい——ここに着目したのがHARPです。基準を書かせるのではなく、過去の判断から基準を推し量る、という設計になっています。

なお、脆弱性の優先度が立場によって変わるという考え方自体は新しいものではなく、CERT/CCが提唱するSSVC（Stakeholder-Specific Vulnerability Categorization）としてすでに枠組み化されています。HARPはその発想を、決定木ではなくLLMによるランキングで実装したもの、と捉えると位置づけが分かりやすくなります。

HARPの仕組み：知識グラフ＋3つの視点＋過去事例

1. 脆弱性ナレッジグラフから根拠を集める

CVE・製品・ベンダー・CWE（脆弱性の種類）・参照情報をノードとし、「どのCVEがどの製品に影響するか」「どの分類に属するか」を辺で結んだグラフを作ります。素材はCVEレコードに加え、既知悪用脆弱性リストや公開エクスプロイトのリポジトリで補強されており、悪用コードの有無・悪用の観測状況・パッチ関連の参照といった情報が乗ります。

2. 3つの視点で別々に採点する

同じ候補情報（説明文・深刻度スコア・悪用シグナル・影響製品・脆弱性分類・ベンダー・参照）を、3つの視点でそれぞれ採点します。

  • グローバル視点：一般的なリスクの大きさ（深刻度・悪用容易性）。方針5種
  • エンタープライズ視点：組織にとっての関連度（影響製品・露出・修正の実行可能性）。方針4種
  • ユーザー視点：エンドユーザーへの影響。方針3種

3. 過去の判断から「視点の重み」を決める

ここがHARPの核です。同じ優先度シナリオで過去にラベル付けされた事例の集合（サポートバンク）から3件をサンプリングし、その3件の正解順位を最もよく再現するように、3視点のスコアをどの比率で混ぜるかの重みをランキング損失で当てはめます。スコアはあらかじめ計算済みなので、この重み推定自体はLLM呼び出しに比べて軽い、と説明されています。

つまり「うちはパッチが出ているものを優先する」と書く代わりに、過去にそう判断した3件を見せるだけで方針が伝わる、という設計です。

実験結果：業界指標ベースラインの0.50に対しHARPは0.84

評価は3つの優先度シナリオで行われました。importance（一般的なリスクと深刻度を重視）、exploit_first（実際に悪用されているものを重視）、patch_order（修正の実行可能性とパッチ提供状況を重視）の3種です。

データセットは各シナリオ12,000件のクエリ・候補ペアで、サポート1,200件（10%）／訓練4,800件（40%）／開発1,200件（10%）／テスト4,800件（40%）に分割されています。正解順位はセキュリティ実務者がシナリオ別のガイドラインに沿って付与し、不一致は議論して合意したものです。

以下はpatch_orderシナリオで、バックボーンLLMにQwen2.5-7B-Instructを使った場合の数値です（Kは候補数の3割）。

手法 P@K MAP@K MRR@K
HARP 0.8404 0.7417 0.6530
LLM-KG-RAG（外部手法で最良） 0.7252 0.6393 0.5723
Industrial Signals（CVSS・EPSS相当・KEV相当を特徴量として学習） 0.4966 0.3621 0.3327
BM25（キーワード検索） 0.4755 0.3703 0.3277
Embedding Ranking 0.4459 0.3306 0.2996

他のシナリオでもHARPの値はほぼ横ばいで、importanceが0.8337、exploit_firstが0.8336（いずれもP@K）。シナリオが変わっても同じ枠組みで追従できている点が、この研究の主張の中心です。バックボーンにはGPT-OSS-20B、Llama3-8B、Qwen2.5-7B-Instructの3種が使われています。

どの部品が効いているのか

アブレーション（部品を外した比較）では、3視点を等重みで混ぜると0.8404から0.7809へ、サポートバンクを別シナリオのものと混ぜると0.7835まで落ちました。「シナリオに合った過去事例で重みを決める」という部分が効いていることを示しています。

この数字をどう読むか

ここは冷静に見る必要があります。正解データ自体が「そのシナリオのガイドラインに沿って人が付けた順位」なので、この課題設定での数字はそのまま実務の的中率とは読めません。Industrial Signalsは論文の説明では固定の計算式ではなく、CVSS・EPSS相当・KEV相当やパッチ提供状況などを特徴量として学習するランカーですが、HARPのように「そのシナリオの過去事例」を推論時に参照する仕組みは持ちません。0.4966という数字は「CVSS・EPSS・KEVの組み合わせが実務で半分しか当たらない」という意味ではなく、「シナリオ固有の人手ランキングを再現する課題で、過去事例を参照しない手法が出した値」という意味に近いものです。

そのうえで、留意点は次のとおりです。

  • 査読前の研究であり、結果は今後変わりうる。1本の論文を過度に一般化しない
  • ベンチマークは3つのシナリオと英語のクエリに限られ、公開されたCVE情報から構築されている。自社の資産台帳や組織固有の修正ワークフローへの接続は今後の課題と論文自身が明記している
  • 推論では視点ごとに複数回のスコアリング呼び出しが発生し、実行時間は候補数とハードウェアに左右されると述べられている
  • 正解ラベルは人手の合意によるもので、別の実務者集団なら別の順位になりうる

「AIが脆弱性の優先度を決めてくれる」ではなく、「組織の判断のクセを、事例から機械に写し取れるか」を検証した研究と読むのが妥当です。評価の枠組み自体を疑ってかかる必要がある点は、AIトリアージの保証は「何もしない」でも達成｜研究解説で扱った構造とも通じます。

現場目線：効くのは「基準を書かなくていい」ところ

正直なところ、脆弱性トリアージの自動化で毎回つまずくのは、モデルの性能ではなく「自社の判断基準を言葉にする」工程です。「重要度が高いものから」と書いても、では公開Webサーバの中リスクと社内システムの高リスクのどちらが先か、と問われると担当者ごとに答えが割れます。ルールに落とそうとすると例外だらけになり、結局は経験のある担当者が勘で並べている——というのが実感に近いのではないでしょうか。

HARPの発想が刺さるのはここです。基準を書き下せなくても、過去に下した判断が残っていれば方針は伝わる。逆にいえば、「なぜその順で対応したか」を記録に残していない組織は、将来この種の仕組みに乗れないということでもあります。わずか3件で重みが変わるという実験結果は、記録の質がそのまま出力の質になることを示しています。

限られた人員で月に数百件の更新を捌く現場では、全件を等しく追うのは初めから無理です。Microsoft月例パッチ569件、AIが変える脆弱性対応で触れたとおり、ベンダー側のAI活用によって公表件数はむしろ増える方向にあります。件数を追う運用から自組織の基準で絞る運用へ寄せる必要があり、その基準を明文化・記録化しておくことが、AI活用の前提条件になります。

いま現場でできること

研究成果を待つ前に、既存の公的・業界指針で足場を作れます。自前で長大なルール表を作るより、確立した枠組みに自社の事情を当てはめるほうが早く、経営層への説明もしやすくなります。

あわせて、スコアの意味を担当者間で揃えておくことも欠かせません。基礎はCVSSとは？脆弱性の深刻度を評価する仕組みと使い方を、アラート判定へのAI適用の現在地はSOCのアラート判定AI、推論で精度向上｜研究解説もあわせてご覧ください。

まとめ

  1. HARPは、優先度の基準を文章化せず過去の判断事例3件から視点の重みを学習してCVEを並べ替える査読前研究。3視点を等重みにすると精度が明確に落ち、事例による適応が効いていることが示された
  2. 報告値はP@K 0.8404（業界指標を特徴量として学習するベースラインは0.4966）だが、正解がシナリオ固有の人手ランキングである以上、過去事例を参照しない手法が不利になる設計。数字は割り引いて読む
  3. 実務への含意は「AIに任せる」ではなく「判断の記録を資産として残す」。SSVCの決定木などで自社基準を可視化しておくことが、将来の自動化の前提になる

出典

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