脆弱性の優先順位付け：何から修正すべきかを決める方法

深刻度だけでは機能しない理由

よくあるのは、CVSSで並べ替えてCriticalから順に対応する方法です。客観的に思えますが、3つの理由でうまくいきません。

CVSSが測るのはリスクではなく深刻度です。悪用された場合にどれほど深刻かを示すもので、誰かが実際に悪用しているか、自社製品にとって重要かどうかは示しません。
リストの大半が緊急扱いになります。公開されたCVEの多くはHighやCriticalと評価されるため、CVSSで並べたキューでは数百件の検出結果が上位に並び、その中から選ぶ手段がありません。
リストの質はインベントリの質で決まります。ロックファイルを読み取るスキャナーは、出荷されることのない開発用の依存関係を報告する一方、ビルドがパッケージマネージャーを介さずにダウンロードしたパッケージを見逃します。どちらも、順位付けが始まる前に結果をゆがめます。

優先順位付けは、欠けている問いを補います。それは悪用されているか、悪用される可能性はどれくらいか、悪用されたら自社にどんな影響があるか、です。ただし、順位付けは目の前のリストを並べ替えるだけです。そのため、まずノイズを減らしましょう。出荷しないコンポーネントの検出結果、重複、担当者のいない検出結果です。

シグナル

シグナル	答える問い	情報源
CVSS	悪用された場合どれほど深刻か。0〜10で評価。	FIRST（標準）。NVDとベンダーがスコアを公開
EPSS	今後30日以内に悪用される可能性はどれくらいか。0〜1の確率。	FIRST、毎日更新、無料
CISA KEV	すでに実環境で悪用されているか。	CISAのKnown Exploited Vulnerabilitiesカタログ
SSVC	悪用状況、影響、自社のミッションを踏まえ、何をすべきか（Track、Attend、Act）。	CERT/CCとCISAの決定木
自社の状況	脆弱なバージョンは出荷されるか。外部に露出しているか。製品はどれほど重要か。修正はあるか。	自社のインベントリ、アーキテクチャ、資産記録

公開されているシグナルが示すのは脆弱性そのものです。自社のリスクを示すのは自社の状況だけであり、多くのチームはその部分を最も信頼性の低い情報源から得ています。

実践的な優先順位付けの手法

多くの取り組みは、最終的に次のような段階に落ち着きます。対応期限は、自社のポリシーや顧客の要求に合わせて設定してください。

今すぐ修正：出荷しているソフトウェアで悪用が確認されているもの。KEVリストに掲載されているか、その他の悪用のエビデンスがあり、リリース済みのビルドに含まれるもの。参考までに、CISAのBOD 26-04は、外部に公開されたシステム上のKEV掲載項目について、米国連邦機関に最短3日の対応期限を課しています。
次に修正：悪用される可能性が高く、深刻なもの。EPSSスコアが高く、CVSSがHighまたはCriticalで、出荷され外部に露出しているコンポーネントにあるもの。チームが実際に処理しきれる規模のキューになるEPSSのしきい値を選んでください。
定期的に修正：出荷されるそれ以外のすべて。検出結果を1件ずつインシデントとして扱うのではなく、定期的な依存関係のアップグレードにまとめます。
文書化：影響なし。脆弱なパッケージは存在するが脆弱なコードは使われていない、またはそのコンポーネントが出荷されない場合です。判断の根拠をVEXステートメントとして記録すれば、同じ検出結果が再びレビューに戻ってくることはなく、問い合わせた顧客にも理由を示せます。

そのうえで、継続的に順位を付け直します。3番目の段階にあった脆弱性も、KEVに追加されたりEPSSスコアが跳ね上がったりすれば、一夜で1番目の段階に移ります。

順位付けの対象にすらならない脆弱性

どの優先順位付けの手法も、目の前にある検出結果を順位付けします。スキャナーが一度も見ていない脆弱なパッケージは検出結果を生まないため、CVSSスコアもEPSSスコアもKEVとの一致も得られません。低い順位が付くのではありません。まったく順位付けされないまま、出荷されてしまうのです。

これは思われているよりも頻繁に起こります。ほとんどのスキャナーは、ロックファイル、マニフェスト、ビルドの出力といったファイルから、ソフトウェアに何が含まれているかを割り出すからです。ビルドが取得するもののうち、どのロックファイルにも載っていないものは隠れた依存関係であり、ファイルベースのツールはそれを見逃します。

インストールフック。npmのpreinstallとpostinstallスクリプトがダウンロードするコードです。Shai-Huludワームが使った経路でもあります。
ビルドスクリプト。たとえばビルド時にコードをダウンロードするRustのビルドスクリプトです。
ベースイメージ。コンテナビルドのベースイメージとそのOSレイヤーです。
キャッシュ。ロックファイルからインストールされるのではなく、CIキャッシュから復元されたパッケージです。

後から出力をスキャンしても、この隙間は埋まりません。完成したバイナリ、特にRustのようなコンパイル済みコードでは、スキャナーは何が含まれているかを推測するしかありません。また、ビルドはデフォルトでは再現可能ではないため、後から同じコミットをビルドし直しても同じ依存関係になる保証はありません。

ビルド時SBOMは反対側から始めます。CRACIはGitHub Actionsのジョブを実行し、各ビルドに入ってくる通信を観測するため、隠れた依存関係も含め、ジョブが実際に取り込んだすべてのパッケージを記録します。各SBOMには完全性の状態があり、観測できなかったものがある場合はそれを示します。実際に、CRACIはSnykやAikidoが報告しなかった脆弱なパッケージを見つけています。それらのツールのスキャンではコンポーネントが欠けていたからです。これこそ、優先順位付けの手法が順位を付ける機会すら得られない検出結果です。

自社の状況：スキャナーがスコア化できない部分

脆弱なバージョンは実際に出荷されているか

最も多くのノイズを取り除くのがこの問いです。ロックファイル内のテストフレームワーク、リリースされないブランチで固定されたパッケージ、破棄されるコンテナのステージは、いずれも顧客には届きません。ビルド中に記録されたSBOMは、リポジトリが宣言している内容ではなく、リリースビルドが実際に使ったものからこの問いに答えます。

どのリリースに、いつから含まれているか

顧客に出荷している製品にあり、昨年の春以降のすべてのリリースが影響を受けている検出結果は、社内ツールにある同じ検出結果よりも優先されます。影響を受けていた期間がわかれば、何を開示すべきかもわかります。

脆弱なコードに到達できるか

到達可能性分析は、自社のコードが依存関係内の脆弱な関数を呼び出せるかを追跡します。いくつかのSCAツールが提供しており、到達できない検出結果をリストの下位に押し下げるのに効果的です。ただし入力の1つとして扱ってください。分析が追跡できるコードパスしか見えず、到達可能な関数が悪用可能な関数と同じとは限りません。

外部に露出しているか、修正はあるか

インターネットに公開されたサービスは、プライベートネットワーク上のバッチジョブよりも優先されます。修正済みバージョンがある脆弱性は、緩和策が必要な脆弱性よりも低いコストで対処できます。どちらも対応の順番を変えるものであり、対応するかどうかを変えるものではありません。

リスクベースの脆弱性管理

リスクベースの脆弱性管理とは、同じ考え方をプログラム全体として捉えた呼び方です。悪用のエビデンス、可能性、深刻度、ビジネス上の状況で順位を付け、最もリスクの高い検出結果がどれだけ早く解消されるかを測定し、リスクの低い検出結果は未解決のまま残る場合があることを受け入れます。指標もそれに合わせて変わります。未解決の脆弱性の総数ではなく、出荷されたソフトウェアで、悪用が確認された既知の脆弱性がいくつ未解決のまま残っているか、そしてどれだけの期間未解決なのかを追跡します。

脆弱性の優先順位付けツール

現在、順位付けの大部分を担っているのは3種類のツールです。

インフラ向け脆弱性管理プラットフォーム：Tenable、Qualys、Rapid7など。悪用に関するインテリジェンスに基づく独自のリスク評価で、ホスト、エンドポイント、クラウド資産をスコア化します。
SCAとアプリケーションセキュリティツール：Snyk、Endor Labs、Semgrepなど。依存関係の検出結果を順位付けし、その一部は到達可能性分析を備えています。
オープンソースツール：検出結果とともにEPSSとKEVのデータを報告するGrypeや、SBOMを継続的に分析するDependency-Trackなど。

脆弱性管理ツールの比較で、それぞれを1つずつ解説しています。

CRACIによる優先順位付けの支援

CRACIは、順位付けが最もよく誤る出発点であるインベントリから取り組みます。GitHub Actionsのジョブを実行し、推移的依存関係、キャッシュから復元されたパッケージ、どのロックファイルにも載らない隠れた依存関係を含め、各ジョブが実際に取得したパッケージを記録します。

出荷したものに対する検出結果。監視対象のSBOMは継続的に再評価され、組織ビューではビルドとリポジトリをまたいで検出結果が集約されます。各パッケージには、深刻度付きのアドバイザリと、そのパッケージを取り込んでいるパッケージが表示されます。
影響を受けていた期間。ビルド履歴から、直接か推移的かを問わず、過去のどのビルドに脆弱な依存関係が含まれていたかがわかるため、どのリリースがどれだけの期間影響を受けていたかを把握できます。
トリアージと担当チームへの割り当て。セキュリティチームは検出結果をトリアージし、それぞれを修正を担当するチームに送ります。CRACIは、脆弱性が自社製品に影響しないことを記録するためのVEXに対応しています。
ゲート。ポリシーゲートで、特定のCVEを含むビルドなど、検出結果に応じてビルドをブロックできます。

CRACIは到達可能性分析を提供していません。それが最も必要なシグナルであれば、到達可能性分析を提供するSCAツールのいずれかをお選びください。機能の全体像は脆弱性トラッキングをご覧ください。

脆弱性の優先順位付けに関するよくあるご質問

脆弱性の優先順位付けとは何ですか？

脆弱性の優先順位付けとは、既知の脆弱性のうち、どれを最初に修正し、どれを後回しにでき、どれがそもそも影響しないかを決めることです。深刻度だけでなく、悪用される可能性と、自社の環境で悪用された場合の被害の大きさによって検出結果を順位付けします。

脆弱性の優先順位はどのように付けますか？

まず正確なインベントリを用意し、実際に出荷されるソフトウェアの脆弱性を順位付けできるようにします。CISAのKnown Exploited Vulnerabilitiesリストに掲載されたものを最優先とし、残りを悪用の可能性（EPSS）と深刻度（CVSS）で順位付けし、露出度、製品の重要度、修正の有無といった自社の状況で調整します。影響のないものはVEXステートメントとして記録します。

脆弱性の優先順位付けにはCVSSだけで十分ですか？

いいえ。CVSSが測るのは脆弱性の深刻度であり、悪用される可能性や自社にとっての重要度ではありません。CVSSだけで順位を付けると、バックログの大部分がHighやCriticalとなり、しかもその脆弱性のほとんどは一度も悪用されません。

リスクベースの脆弱性管理とは何ですか？

リスクベースの脆弱性管理とは、CVSSスコアや経過日数の順に処理するのではなく、悪用のエビデンス、可能性、深刻度、ビジネス上の状況を組み合わせ、組織にもたらすリスクに基づいて脆弱性を順位付けし、修正する手法です。

EPSSとKEVの違いは何ですか？

EPSSは予測であり、CVEが今後30日以内に悪用される推定確率です。KEVは記録であり、実環境での悪用のエビデンスがある脆弱性をまとめたCISAのカタログです。KEVへの掲載は事実であり、EPSSスコアは可能性です。まずKEVを使い、それ以外のすべてをEPSSで順位付けしてください。

到達可能性分析は優先順位付けの代わりになりますか？

いいえ、入力の1つが増えるだけです。到達可能性分析は、自社のコードが依存関係内の脆弱な関数を呼び出せるかを確認します。発動し得ない検出結果を除外できますが、悪用の可能性については何もわからず、分析が追跡できるコードしか対象になりません。