脆弱性管理
スキャン結果を「直す優先度」に変える
脆弱性は数が増えるほど、判断が遅れ、直し漏れが増えます。ここでは「何から直すべきか」を自動化しやすい形に落とし込みます。評価軸は、影響範囲、悪用可能性、そして実装上のリスク耐性です。
1. まずはスキャン結果を“使える粒度”に揃える
スキャナの生データのまま優先度を付けると、同じ問題が重複して見えたり、適用範囲が曖昧で比較できなくなります。最初に、次を整えます。
- 重複の統合：同一CVE・同一影響コンポーネントは統合し、対象資産の一覧にする。
- 影響面の定義：サービス名、到達経路（外部公開/内部限定）、認証の要否を揃える。
- 現実的な修正単位：パッチ適用、設定変更、代替策のどれで解消するかを決める。
2. 優先度スコアの設計は「意思決定」に寄せる
優先度スコアは、単なる点数ではなく「次の週に着手する理由」を作る道具です。おすすめは、ベース評価と組織固有の補正を分ける方式です。
ベース評価（標準寄り）
- 悪用可能性（公開状況、攻撃の再現性、既知の悪用例）
- 影響（権限昇格、情報漏えい、RCEなどの結果の大きさ）
補正（組織寄り）
- 到達経路（インターネット公開、踏み台の有無、横展開のしやすさ）
- 修正の実装リスク（停止不可、互換性、手順の複雑さ）
- 検知と監視（兆候の観測可能性、代替検知の有無）
ヒント：スコアは0〜100でなくても構いません。重要なのは「同点になった場合の扱い」と「誰がいつ再計算するか」です。
3. “修正が難しい”脆弱性に道筋を作る
全てをパッチで即時に直すのは現実的ではありません。その場合でも優先度は意味を持ちます。方針は「直す」「回避する」「抑え込む」の選択肢で整理します。
直す（パッチ/アップデート）
- 優先度上位は検証環境で先行適用
- リリース手順とロールバック条件を事前に確定
回避/抑え込み（設定・隔離・緩和策）
- 攻撃面の縮小（公開範囲の見直し、無効化）
- 補助検知（ログ項目の追加、アラート閾値の調整）
重要なのは「いつまでに」「何をもって完了」とするかです。作業チケットには、修正内容だけでなく“完了条件”を明記します。
4. 値の大きいスキャンではなく“直すべき順”で更新する
スキャン結果は増え続けます。だからこそ、更新の粒度は「優先度の変化」に寄せます。例えば、次のタイミングで再計算すると運用が安定します。
- 重大度の根拠が変わった（新たな悪用情報が出た、攻撃手法が確立した等）
- 資産の到達経路が変わった（公開範囲の変更、ネットワーク再設計）
- 緩和策が追加された（監視強化、隔離ルールの導入）
- 修正が進んだ（適用完了、部分適用、ロールバックの発生）
5. その場しのぎを防ぐチェックリスト
優先度を付けた後に、抜けやすい確認項目を固定化します。
- 重み付けの根拠：スコアの主要因が説明できる（属人化しない）。
- 再評価の条件：いつ再計算するかが文書化されている。
- 完了条件：修正の成否を検証する方法（検査手順、ログ確認、スキャン再実行）がある。
- 緩和策の期限：一時対応は期日と後続アクションを持つ。
まとめ
脆弱性管理は「見つける」より「直す順を決める」ことで前進します。スキャン結果を使える粒度に整え、影響と悪用可能性に加え、到達経路と修正リスクを補正しましょう。そして、直すだけでなく回避や抑え込みにも道筋を付けます。最後に、再評価条件と完了条件を固定化することで、運用がブレなくなります。
次に読むなら、関連記事で周辺テーマも押さえるのがおすすめです。