脆弱性の優先順位付け：KEV・EPSS・到達可能性の組み合わせ
3000 対 20 の落差
全量スキャンが 3000 件を報告し、そのうち「高」と「緊急」が 600 件。セキュリティチームが一覧を開発へ渡すと、開発側はそれを一目見てきわめて妥当な問いを返します。どれから直すのか、と。
この問いに答えがない場合、次に起きるのはたいてい二つのうちどちらかです。一覧が無期限に棚上げされるか、深刻度の高い順に機械的に処理し、実際のリスクが低い項目に多くの労力を費やすか。どちらも望ましくありません。
優先順位付けの方法論は、この落差を埋めるために存在します。要点はここにあります。単一の指標では答えを出せません。それぞれが答えている問いが、そもそも同じではないからです。
4 つの判断材料、4 つの問い
### CVSS：この脆弱性は理論上どれほど深刻か
CVSS は脆弱性そのものの技術的特性——攻撃経路、複雑さ、必要な権限、影響範囲——を評価します。その価値は、組織をまたいで比較できる深刻度の基準を提供する点にあります。
限界：CVSS が記述するのは「悪用されたらどうなるか」であり、「悪用されるかどうか」や「自社の環境で悪用できるかどうか」には触れません。9.8 の脆弱性でも、公開された悪用コードがなく、該当機能が自社の構成では到達不能であれば、実際のリスクは大規模に悪用されている 6.5 より低いことがあります。
CVSS を唯一の並べ替え基準にすることは、脆弱性管理で最も多い誤りです。
### KEV：この脆弱性は今まさに悪用されているか
CISA が維持する既知悪用脆弱性カタログ（Known Exploited Vulnerabilities）には、実際の攻撃で使われている確たる証拠のある脆弱性が記録されています。
これは二値で信頼度の高い信号です。KEV に載っているということは、攻撃がすでに起きているという意味であり、理論上の推論ではありません。企業にとって、KEV に該当する脆弱性は CVSS の値にかかわらず最優先とすべきです。実際に攻撃されている 7.5 は、誰も手をつけていない 9.8 よりはるかに緊急です。
KEV の限界は網羅範囲です。観測された悪用のみを含むため、新しく現れた脆弱性や標的型攻撃で使われるものは、すぐには現れません。
### EPSS：今後 30 日以内に悪用される確率はどれくらいか
EPSS（Exploit Prediction Scoring System）は FIRST が維持し、機械学習モデルによって、ある脆弱性が今後 30 日以内に悪用される確率を 0 から 1 の値で予測します。
これは KEV が残す空白を埋めるものです。KEV は「すでに悪用されている」を、EPSS は「これから悪用されうる」を伝えます。モデルの入力には、脆弱性の特徴、悪用コードの公開状況、コミュニティでの言及の多さなどが含まれます。
実務的な価値：大多数の脆弱性の EPSS 値は非常に低く（万分の数程度）、警戒すべきは値が明確に高い少数です。これにより数千件の中から高確率の対象を素早く絞り込めます。
### 到達可能性分析：自社のコードでその脆弱性は発火しうるか
前の 3 つはいずれも「脆弱性そのものについて」の判断材料ですが、到達可能性分析が答えるのは自社についての問いです。脆弱性のある関数を、自分のコードは実際に呼んでいるのか。呼び出し経路上の引数は攻撃者に操作されうるのか。発火条件は自社の設定で成立するのか。
作業量を大幅に削減できる唯一の判断材料がこれです。実務では、多くの部品の脆弱性が一度も使っていない機能領域に位置しています。依存関係としては存在するが、そのコードは決して実行されない、という状態です。これを識別できれば、対応リストを一桁縮められます。
VEX が存在する意味もここにあります。「影響を受けない」という判断を標準化して出力し、下流が同じ分析を繰り返さずに済むようにするためです。
組み合わせて使う
4 つの判断材料の正しい関係は「一つを選ぶ」ではなく、階層的な絞り込みです。
第 1 層・即時修正：KEV に該当するもの。悪用が進行中であり、議論の余地はなく、緊急手順に入ります。
第 2 層・今サイクル内で修正：EPSS が高い（自社で定めたしきい値を超える）かつ到達可能性が「発火しうる」と確認されたもの。まだ大規模な悪用には至っていないが確率が高く、自社環境で実際にリスクが存在する層です。
第 3 層・計画的に修正：CVSS が高く到達可能だが EPSS は低いもの。実在するリスクですが外部からの切迫した圧力はなく、通常の反復に組み込みます。
第 4 層・記録して監視：到達可能性の判断が「影響を受けない」となったもの。無視するのではなく、判断根拠を記録し（VEX を生成し）、環境が変わった時点で再評価します。今日到達不能なコードが、明日のリファクタリングで到達可能になることがあります。
この階層化の要点は、「3000 件の未対応」を「十数件の緊急 + 数十件の今サイクル + 残りは計画と監視」に変えることであり、これはチームが実際に実行できる規模です。
実務上の細部
しきい値は自分で決めます。他所の数値を写さないでください。 EPSS の何点を高いとするか、CVSS をどこから拾うかは、業種、露出面、チームの処理能力によって変わります。対外の中核サービスと社内ツールで、しきい値が同じであるべき理由はありません。
判断を蓄積し、同じ作業を繰り返さないでください。 チームが時間をかけて「これは影響を受けない」と結論づけたなら、その結論は記録され、再利用され、環境の変化で再度検証されるべきです。VEX はまさにそのための標準的な器です。
修正だけが選択肢ではありません。 バージョン更新、パッチ適用、設定による緩和、隔離、部品の差し替え。それぞれ費用と所要時間が大きく異なります。優先順位付けの出力は「これは修正が必要」ではなく「これはどの対応経路をとるか」であるべきです。
全体の傾向も見てください。 個別の対応の外側で注目すべきは、在庫が収束しているかどうかです。未対応件数の推移、平均修復時間（MTTR）、期限超過の比率。これらの指標こそが、脆弱性管理の体制が改善しているのか劣化しているのかを教えてくれます。
「検出した」から「対応しきる」へ
脆弱性管理の成熟度は、スキャナが何件報告したかではなく、報告された項目のうちどれだけの割合が妥当に処置されたかに表れます。
検出能力はもはやボトルネックではありません。現在の工具が報告できる量は、どのチームの処理能力をも超えています。真のボトルネックは判断です。どれが本当のリスクか、どれは待てるか、どれはそもそも修正不要か。そしてその判断の質は、これら 4 つの判断材料を組み合わせて使えているかどうかで決まります。
---
関連記事：CI パイプラインでの SCA ゲート設定 · OSS・SBOM 実践ガイドの CVSS・EPSS・VEX 項目 · CleanSource SCA の到達可能性分析
