managing-vulnerabilities

脆弱性の管理

スキャナーの検出結果は1万件に上り、その大半が「高」または「重大」と評価されていますが、チームが1か月にパッチを適用できるのは数百件です。脆弱性管理とは、どの数百件に対応するかを決める機能です。「CVSSの高い順に並べる」というデフォルトの方法は、最悪に近い順序です。CVSSが測定するのは理論上の深刻度であり、この資産にあるこの脆弱性が悪用される確率ではないためです。

この分野の目的は、区別のないバックログを、限られたチームが実際に実行できる、説明可能な作業順序へと変えることです。

使用する場面

• 脆弱性スキャナーの出力をトリアージし、修復の順序を決める
• 修復に使える予算が固定されている状況で、どれからパッチを適用するかを決める
• リスクベースの脆弱性管理プロセスを構築またはレビューする
• CVSS 9.8の脆弱性が今週の最優先事項ではない理由を説明する
• 検出結果に対し、修正ではなく例外を認めるべきか判断する

使用しない場面

• セキュリティ アラート のキューに対応する場合（EDR／SIEMの検知） — triaging-security-alerts を使用します。こちらは検知された活動であり、ここで扱うのは潜在的な弱点です
• 新たな脆弱性を探すためにソースコードを監査する場合 — auditing-code-for-vulnerabilities を使用します
• ソフトウェアのCVEではなく、クラウドの設定ミスを扱う場合 — hardening-cloud-posture を使用します
• 脆弱性を悪用して実証する場合 — 該当する攻撃側のスキルを使用します

CVSSが示すのは深刻度であり、優先度ではありません

CVSSの基本スコアが答えるのは、「抽象的に見て、悪用された場合にどれほど深刻か」です。「ここで悪用される可能性はどれくらいか」ではありません。実際の修復順序を左右するのは後者の問いです。証拠は明白です。CVEの大半は実環境で悪用されたことがない一方で、その多くが「高」または「重大」と評価されています。CVSS順に並べると、実際には攻撃されない脆弱性にチームの限られた対応能力を費やし、実際に悪用されている脆弱性がその後ろで待つことになります。

CVSS 4.0は入力のひとつ、つまり深刻度を示す指標として使い、悪用の確率と対象環境での影響を示すシグナルと組み合わせてください。

組み合わせるべき3つのシグナル

1. 悪用されていますか？ — EPSSとKEV

• CISA KEV（既知の悪用済み脆弱性）。 実環境での悪用が確認・観測されたCVEをまとめた厳選カタログです。KEVに掲載されていることは、利用可能な優先順位付けのシグナルの中で最も強力です。これは予測ではなく、悪用されたという事実です。環境内にKEVリスト掲載の脆弱性があれば、対応順を繰り上げてください。米国連邦政府機関にとって、KEVには拘束力のある修復期限も設定されています。期限に拘束されない場合でも、妥当な標準として扱ってください。
• EPSS（Exploit Prediction Scoring System）。 CVEが今後30日以内に悪用される確率を、0から1の範囲で予測する、毎日更新の機械学習ベースの指標です。これは観測された事実ではなく予測であり、ランキングではなく確率です。0.90は約90％の確率を意味し、ほとんどのCVEは0.10を大きく下回ります。まだKEVに掲載されていない長い裾野の順位付けに使用してください。毎日更新されるため、データを再取得してください。悪用ツールが登場すると、CVEのEPSSが急上昇することがあります。

KEVとEPSSは、「悪用が確認済みか」と「悪用されそうか」という異なる問いに答えるため、両方が必要です。KEVは確実性の基準となり、それより下にあるすべてのものをEPSSで順位付けします。

2. 到達可能ですか？ — 露出状況とコンテキスト

存在していても到達できない脆弱性と、攻撃者がアクセスできる脆弱性は同じではありません。

• 影響を受けるサービスは、インターネットに公開されていますか、内部専用ですか、それとも隔離されたセグメントにありますか？
• 脆弱なコードパスは実際に呼び出されていますか。それとも、依存関係として含まれているだけで、呼び出されることはありませんか？（到達可能性の分析については、依存関係のケースを扱う auditing-supply-chain を参照してください。）
• 悪用の前提条件を崩す補完的な制御（WAFルール、ネットワークポリシー、無効化された機能など）はありますか？
• 悪用に認証、ローカルアクセス、またはユーザー操作が必要で、配置状況から見てそれらが起こりにくいですか？

インターネットに公開され、認証不要で、KEVに掲載されたRCEと、内部にあり、認証が必要な、同じCVSSスコアのバグでは、スコアがどうであれ優先度は同じではありません。

3. 何を保護するのか？ — 資産価値

ドメインコントローラー、最重要データベース、開発者が使い捨てる VM で同じ脆弱性が見つかったとしても、それぞれ緊急度は異なります。発見事項を資産の重要度に結び付けてください。資産インベントリのない脆弱性管理プログラムは、何も見えないまま優先順位を付けているのと同じです。

単一の数値ではなく、SSVC で判断する

すべてを単一のスコアに集約するのではなく、意思決定ツリー方式（SSVC — ステークホルダー固有の脆弱性分類）では、上記の質問を順番に問い、次のアクションにたどり着きます：悪用状況 → 露出状況 → 自動化可能性 → 影響 → {追跡／追跡／対応／対処}。* この方式の利点は、「スコアが 8.7 だった」と言うだけでは決して得られない形で、作業を行うチームにも、例外を承認するリスクオーナーにも、各判断を説明できることです。

どのような方法で分類するにしても、成果物はリスクスコアではなく、担当者と期限を明記した、実行可能な優先順位付きリストでなければなりません。プログラムの成果は、ダッシュボードではなく、パッチ適用済みのシステムです。

修正と例外を正確に追跡する

• **発見事項は修正が確認されるまで未解決です。**チケットがクローズされるまでではありません。再スキャンして確認してください。「パッチを適用した」と「検出されなくなった」は、異なる主張です。
• **例外とは、担当者と有効期限を伴う判断です。**ひそかな抑制ではありません。氏名もレビュー日もない「リスク受容」が、KEV の CVE を 1 年間も未解決のままにする原因です。
• **再発はプロセス上の問題です。**修正後に同じ脆弱性が再発するなら、ベースイメージ、ゴールデンテンプレート、またはパイプラインによって再び持ち込まれています。クラウドのガードレールが場当たり的な修正に勝るのと同じように、個々のインスタンスではなく、原因を修正してください。

却下すべき誤った認識

• 「9.8 だから最優先です。」 CVSS が示すのは深刻度であり、悪用される確率ではありません。KEV に登録されておらず、EPSS が低く、隔離された内部ホストにある 9.8 は、KEV に登録され、インターネットに公開されている 7.5 より優先度が低くなります。
• 「たかが 5.3 だから無視できます。」 KEV に登録され、到達可能な場合はそうではありません。実際に観測された悪用は、中程度の深刻度スコアよりも優先されます。
• 「Critical はすべて 30 日以内にパッチを適用します。」 深刻度だけに基づく一律の SLA では、予算を誤った基準で使うことになります。悪用され、到達可能なものには数日以内にパッチを適用し、悪用されておらず到達不能な Critical は後回しにしてください。
• 「依存関係に脆弱性があるので、こちらも脆弱です。」 脆弱なコードパスに到達可能な場合に限ります。存在していても呼び出されていないコードも、実際に呼び出されるコードと同じ緊急度ではないものの、対応すべきバックログです。
• 「EPSS が低いので安全です。」 EPSS は 30 日間の予測値であり、変動します。再取得し、KEV が優先されることを忘れないでください。予測よりも、実際に観測された事実が優先されます。
• 「チケットをクローズしました。」 チケットをクローズしても、脆弱性が修正されたことにはなりません。再スキャンして確認してください。そうでなければ、脆弱性は未解決のままです。
• 「リスクを受容しました。」 誰が受容し、いつレビューしたのでしょうか。担当者も有効期限もない例外は、ラベルを貼っただけの管理されていない脆弱性です。

外部ソースの読み込み

公開アドバイザリー、仕様書、ベンダーレポートを Markdown として取得します：

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

これにより、ページの定型部分が取り除かれます。文章主体のページではトークン数が約 78% 減り、要約ではなく全文が返されるため、全文を検索でき、検索結果がなかった場合も信頼できます。

この方法が適さないケースは 3 つあります。JSON と API のレスポンスは、生データのまま取得してください。可読性のための抽出処理によって、構造化データが壊れてしまうためです。認証が必要なページや JavaScript で描画されるページも、直接取得してください。この方法では匿名で取得されるためです。また、攻撃者のインフラ（フィッシングリンク、C2、マルウェアのホスティング先）、クライアント所有のホスト、またはエンゲージメント URLをこの方法で取得してはいけません。リクエストがマシンから第三者へ送信され、稼働中の攻撃者インフラの場合は、オペレーターに気付かれるおそれもあります。

一部のサイトでは抽出ツールがブロックされ、ページの代わりにエラー本文が返されます。たとえば freedesktop.org では、{"error":"Failed to fetch: 418 I'm a teapot"} が返されます。これは取得が拒否されたことを意味し、**ソースに該当する情報が存在しないという意味ではありません。**そこから何らかの結論を出す前に、URL を直接再取得してください。

参考資料

• triaging-security-alerts — この潜在的な弱点への対応に対する、検知された活動への対応です。どちらも限られたリソースのもとで、実際のリスクに基づいて順位付けします
• auditing-supply-chain — 依存関係の到達可能性です。ライブラリの CVE に関するシグナル 2 の入力となります
• hardening-cloud-posture — ソフトウェアの CVE に対する、設定ミスへの対応です
• reporting-security-findings — 優先順位付けしたリスクを担当者に伝えます