「パッチの洪水」に溺れる現代のIT部門
ソフトウェアやシステムを構成するコードには、設計・実装上の欠陥（脆弱性）が必ず存在します。この欠陥を突く攻撃を防ぐため、組織は脆弱性を発見 → 評価 → トリアージ（優先順位付け） → 修正 → 検証するサイクルを永遠に回し続ける必要があります。
しかし2026年現在、CVE（共通脆弱性識別子）の登録数は年間4万件を突破し、パッチのリリースと同時（あるいはそれ以前のゼロデイ）に悪用コード（エクスプロイト）がばら撒かれています。すべてのパッチを即座に当てることは、システム停止のリスクや人的リソースの限界から不可能です。 現代の脆弱性管理（Vulnerability Management）は、「いかに全部直すか」ではなく、**「自社にとってクリティカルな少数の脆弱性を、いかにデータドリブンで特定するか」**というリスクマネジメントの戦いにシフトしています。
識別と評価の基礎：CVE と CVSS
CVE（Common Vulnerabilities and Exposures）
CVEは、世界中で発見された脆弱性に固有のID（例: CVE-2021-44228）を付与する国際的な辞書です。MITRE社や認定されたCNA（採番機関）が登録・管理を行います。これにより、セキュリティベンダーや研究者が「同じ脆弱性」についてブレなく議論できるようになります。
CVSS（Common Vulnerability Scoring System）
CVSSは、脆弱性の技術的な「深刻度」を0.0（無害）から10.0（極めて致命的）のスコアで絶対評価するフレームワークです。
| スコア帯 | 深刻度 (Severity) | 従来の基準による対応目標 |
|---|---|---|
| 9.0〜10.0 | 緊急（Critical） | 即時対応（24〜48時間以内） |
| 7.0〜8.9 | 重要（High） | 迅速な対応（1〜2週間以内） |
| 4.0〜6.9 | 中（Medium） | 定期メンテナンスで対応（30日以内） |
| 0.1〜3.9 | 低（Low） | 計画的な対応 |
CVSS（現在の主流はv3.1、および最新のv4.0）は、以下の指標の組み合わせで計算されます。
- 攻撃元区分（AV）: ネットワーク越しに叩けるか（Network）、物理アクセスが必要か。
- 攻撃条件の複雑さ（AC）: 特殊な設定が必要か。
- 必要な特権レベル（PR）: 認証なし（None）で実行できるか。
- C/I/A への影響: 機密性・完全性・可用性がどの程度破壊されるか。
CVSS至上主義の限界と、新たなトリアージ指標
CVSSが10.0（緊急）であっても、そのシステムが「インターネットから遮断された社内テスト環境」であれば、自社にとってのリスクは低くなります。逆に、CVSSが7.0であっても「インターネットに公開された本番DB」であれば最優先で直すべきです。「深刻度（CVSS）＝ リスク」という誤解が、IT部門を疲弊させています。
真のリスクベース脆弱性管理（RBVM）を実現するために、現在世界のセキュリティチームは以下の新しい指標を組み合わせています。
1. CISA KEV（Known Exploited Vulnerabilities Catalog）
米国サイバーセキュリティ・インフラ庁（CISA）が管理する**「現在、世界で実際にハッカーに悪用されている脆弱性」**のブラックリストです。 CVSSスコアが低かろうと、**KEVに掲載された脆弱性は「すでに火を噴いている状態」**であり、問答無用で最優先パッチ適用の対象となります。
2. EPSS（Exploit Prediction Scoring System）
FIRST（インシデント対応チームの国際フォーラム）が提供する、AIを用いた**「今後30日以内にその脆弱性が実際に悪用される確率（%）」**の予測モデルです。 全CVEのうち、実際に攻撃コードが書かれ悪用されるのはわずか「数パーセント」に過ぎません。CVSSが9.0であってもEPSSが0.1%であれば、攻撃者は見向きもしておらず、パッチ適用に猶予がある（他に優先すべきものがある）と判断できます。
3. SSVC（Stakeholder-Specific Vulnerability Categorization）
カーネギーメロン大学（CMU SEI）とCISAが提唱する画期的なトリアージ決定ツリーです。「スコア」ではなく「取るべき行動」を導き出します。
- 悪用の状況（KEV等） × 対象システムの重要度 × 自社環境での露出度 この3つの変数をツリー上でたどり、最終的に「Track（監視）」「Attend（定期対応）」「Act（優先対応）」「Track*/Attend*（即時対応）」の4つのアクションに分類します。
組織の脆弱性管理アーキテクチャ
強靭な企業は、以下のステップでパッチ管理のパイプラインを構築・自動化しています。
ステップ1: ASM（Attack Surface Management）と構成管理（CMDB）
「自社がインターネットに何を公開しているか（シャドーITを含めて）」を把握できなければ、脆弱性のスキャンすら不可能です。絶えず変化するパブリッククラウドアセットのインベントリを維持します。
ステップ2: 継続的スキャン
Nmapなどのポートスキャンや、Tenable/Qualys等の専用脆弱性スキャナツール、あるいはEDRのエージェントを通じ、インフラ全体の「ソフトウェアとバージョンのリスト（SBOM）」を収集し、CVEデータベースとリアルタイムに突き合わせます。
ステップ3: コンテキスト・トリアージ
前述の「CVSS × KEV × EPSS × SSVC（自社環境での重要度）」をSIEMやSOARに流し込み、「自社の本番環境で、かつ現在攻撃者が実際に使っている脆弱性」だけをトップ10アラートとして抽出します。
ステップ4: テストと段階的デプロイメント
パッチを当てた結果、業務システムが停止（デグレード）しては本末転倒です。影響の少ないステージング環境でのカナリアリリースや検証を経て、ダウンタイムを最小限に本番適用します。適用不可能なレガシーシステムには、WAFやIPSのルールで一時的にブロックする「仮想パッチ」を適用します。
【確認問題】自社のWebサーバーに2つの脆弱性が見つかりました。「脆弱性A」はCVSSベーススコアが 9.8（緊急）ですが、社内LANからしかアクセスできずEPSS（悪用確率）は0.5%です。「脆弱性B」はCVSSベーススコアが 7.5（重要）ですが、インターネットに公開されており、CISA KEV（既知の悪用カタログ）に登録されています。現代的なリスクベース脆弱性管理において、真っ先に緊急対応すべきはどちらですか？