CVEの優先順位付けと是正措置

脆弱性スキャナーの分析結果によると、管理対象のシステム全体で4,000件の未修正のCVEが検出されました。チームは3名体制です。どの脆弱性を優先して修正すべきか、またいかに効率的に修正するかを把握しているかどうかが、リスクを適切に管理できている状態と、セキュリティ侵害が起きるのを待つだけの状態との分かれ目となります。

本ガイドでは、経験豊富なITおよびセキュリティチームが実際にCVEの優先順位付けと修正にどのように取り組んでいるかについて解説します。信頼できるスコアリングシステムの選定、ビジネスコンテキストの考慮方法、そして現代の膨大な脆弱性開示情報に押しつぶされない、再現性のあるワークフローの構築方法について説明します。

CVEの優先順位付けが実際に意味すること

CVE（Common Vulnerabilities and Exposures）とは、公開されたセキュリティ脆弱性を識別するための標準化された識別子です。National Vulnerability Database（NVD）は、Common Vulnerability Scoring System（CVSS）を用いて各脆弱性のスコアを管理しており、CVSSでは深刻度を0から10のスケールで評価します。

優先順位付けとは、チームがどのCVEを最初に修正し、どのCVEを受け入れるか、先送りするか、あるいは代償的対策によって軽減するかを決定するプロセスです。単純そうに聞こえます。しかし、問題なのは、生のCVSSスコアが組織固有のリスクを反映するようには設計されておらず、これを唯一の意思決定材料として扱うと、無駄な労力につながる点です。

自社の環境内のどこにもインストールされていないソフトウェアにおけるCVSS 9.8の脆弱性は、実質的に無関係です。一方、支払いデータを処理する一般に公開されたサービスにおけるCVSS 5.4の脆弱性は、緊急を要します。優先順位付けとは、深刻度を現実の状況に照らし合わせて判断することです。

CVSSスコアだけでは不十分な理由

CVSSは、理想的な悪用条件下における脆弱性の本質的な深刻度を測定するものです。以下の要素は考慮されていません：

• 実環境での悪用可能性。実際に機能するエクスプロイトが存在するか、一般に公開されているか、そして脅威アクターによって積極的に利用されているか。
• 資産の露出状況。脆弱性のあるシステムがインターネットに公開されているか、隔離されているか、あるいはエアギャップが確保されているか。
• ビジネス上の重要度。影響を受ける資産が、中核製品を実行しているか、規制対象データを保存しているか、あるいは開発環境内のテストマシンであるか。
• 既存の対策。補完的な対策（ネットワークのセグメンテーション、EDR、アプリケーションの許可リスト）によって、すでに悪用可能性が低減されているかどうか。

これが、サイバーセキュリティコミュニティが、CVSSを置き換えるのではなく、その上に重ねて適用するリスクベースの脆弱性管理フレームワークへと広く移行している理由です。

現実世界の文脈を加味するスコアリングフレームワーク

EPSS（エクスプロイト予測スコアリングシステム）

インシデント対応・セキュリティチームフォーラム（FIRST）によって維持管理されているエクスプロイト予測スコアリングシステム（EPSS）は、機械学習を用いて、CVEが今後30日以内に実環境で悪用される確率を推定します。 EPSSのスコアは0から1の範囲（確率0％～100％）です。

CVSS の深刻度と高い EPSS スコアが組み合わさることは、その CVE に直ちに対処すべきであるという強力なシグナルとなります。CVSS 7.5 で EPSS スコアが 0.94 のものは、CVSS 9.1 で EPSS スコアが 0.003 のものよりもはるかに緊急性が高いと言えます。

CISA KEV（既知の悪用されている脆弱性カタログ）

CISAの「既知の悪用されている脆弱性カタログ（KEV）」は、CISAが実環境で積極的に悪用されていることを確認したCVEを厳選してまとめたリストです。連邦政府機関は、定められた期限内にKEVに登録された項目に対する是正措置を講じることが義務付けられています。連邦政府機関以外の組織においても、KEVリストに掲載された場合は、通常のSLAにかかわらず、是正措置を加速させるべきです。

CISベンチマークおよびNIST SP 800-40

NIST特別刊行物800-40は、リスクベースの優先順位付け基準を含む、企業のパッチ管理に関するガイダンスを提供しています。CIS重要セキュリティ対策（特に対策7「継続的な脆弱性管理」）では、CVSSスコア、資産の重要度、脅威インテリジェンスの順に、是正措置の優先順位を付けることを推奨しています。

CVE優先順位付けワークフローの構築

再現可能な優先順位付けプロセスは、通常、以下の手順に従います。

1.アセットの棚卸しを行う。把握できていないものを優先順位付けすることはできません。完全かつ最新のハードウェア棚卸しは、あらゆる脆弱性管理プログラムの前提条件です。管理されていないデバイスはすべて、死角となります。

2.継続的な脆弱性スキャンを実行する。スケジュールされたスキャンでは、CVEの公開から次回のスキャンサイクルまでの期間をカバーできません。継続的またはほぼリアルタイムのスキャンにより、そのギャップを埋めることができます。詳細な解説については、『脆弱性スキャン：実務者向けガイド』を参照してください。

3.まずCISA KEVでフィルタリングします。KEVリストに掲載され、自社の環境に影響を与えるCVEはすべて、優先順位リストの最上位に配置します。例外は認められません。

4.残りのCVEを総合リスクに基づいてスコア付けする。CVSS + EPSS + アセットの重要度 + 露出レベルを用いる。スプレッドシートで単純な加重スコアを作成するチームもあれば、専用の脆弱性管理プラットフォームを利用するチームもある。

5.SLAの優先度を割り当てます。一般的な構造は以下の通りです：

-重大（CVSS 9.0以上またはKEVリスト掲載）：24～72時間以内に是正

-高（CVSS 7.0～8.9、EPSSが高い）：7～14日以内に是正

-中（CVSS 4.0～6.9）：30～60日以内に是正措置を講じる

-低（CVSS 4.0未満）：次回の予定されたパッチ適用サイクルで是正するか、文書化された根拠に基づき容認する

6.例外事項を正式に文書化する。SLAの期間内に是正できない場合は、代替対策、業務上の正当性、および見直し日を文書化する。これは、あらゆるコンプライアンスフレームワーク（SOC 2、ISO 27001、FedRAMP）において必須の要件である。

CVEの是正措置：パッチ適用は選択肢の一つであり、唯一の選択肢ではない

是正措置とは、CVEがもたらすリスクを許容可能なレベルまで低減することを意味します。パッチ適用が最も一般的なアプローチですが、その他の選択肢には以下が含まれます：

• ベンダーのパッチを適用する。パッチが存在し、依存システムに支障をきたすことなく展開できる場合は、常にこの方法が推奨されます。
• 設定の変更。一部のCVEは、特定の設定下でのみ悪用可能です。設定を強化することで、パッチ適用なしに悪用可能性を排除できます。
• 代替対策。パッチが利用できない場合や、直ちに適用することが安全でない場合、ネットワークのセグメンテーション、WAFルール、または影響を受ける機能の無効化によって、悪用可能性を低減できます。
• リスクの受容。重要度が低く、非重要かつ隔離された資産におけるCVEについては、文書化された正式なリスク受容も正当な選択肢となります。

是正措置のワークフローでは、テストも考慮に入れる必要があります。段階的な展開を行わずに3,000台のエンドポイントにOSパッチを適用すると、火曜日の朝にはシステム群が機能不全に陥ることになります。 標準的な段階的展開の流れ：カナリアグループ（全端末の1～5％）、パイロットグループ（10～15％）、広範囲展開。

Apple環境におけるCVEの優先順位付け

Appleデバイスのフリートには、特有の考慮事項があります。Appleは、OSアップデートやRapid Security Responses（RSR）を通じて、macOS、iOS、iPadOSの脆弱性に対処します。サードパーティ製ソフトウェアとは異なり、OSのフルアップデートまたはRSRを適用せずに、Apple OSコンポーネントにCVEパッチを適用することはできません。

つまり、Appleデバイスのパッチ適用サイクルは、MDM展開戦略に密接に結びついています。OSアップデートの遅れは、未修正のCVEのバックログを増加させます。OSバージョンやインストール済みソフトウェアのバージョンに関するフリート全体の可視化が、その出発点となります。Appleデバイスの管理に関する基礎知識が十分でない場合、脆弱性の公開から適用までのギャップは、チームが手動で追跡できる速度よりも急速に拡大してしまいます。

Appleはすべてのアップデートについて、CVE IDを参照したセキュリティコンテンツノートを公開しています。これらのノートと、管理対象デバイスの現在のOSバージョン分布を比較することで、各デバイスがどれほど遅れているかを正確に把握できます。

IruによるCVEの優先順位付けと是正へのアプローチ

IruはAppleデバイス群向けに特別に構築されているため、macOS、iOS、iPadOS、tvOSにおけるCVEの脆弱性は、プラットフォームにおいて後付けの機能ではなく、最優先の関心事となっています。

Iruは、デバイス群全体のOSバージョンとインストール済みソフトウェアを継続的に監視します。Appleがセキュリティアップデートをリリースすると、Iruは脆弱なOSバージョンを実行しているデバイスを特定し、その情報をリリースで対処されたCVEと照合します。 これにより、単に「アップデートが利用可能です」というだけでなく、「X台のデバイスが、CISAのKEVリストに掲載されているCVE-2025-XXXXの影響を受けるmacOSバージョンを実行しています」といった形で、具体的なリスク状況を把握できます。

是正措置の実施は、Iruのコンプライアンスエンジンを通じて行われます。OSバージョンの最低基準を定義し、実施期限を設定し、強制的な措置が開始される前にエンドユーザーへの段階的な通知を構成できます。段階的なロールアウトは展開ワークフローに組み込まれているため、カスタムスクリプトを作成することなく、まずテストグループに展開して検証を行い、その後広範囲に展開することができます。

ソフトウェア面では、Iruのマネージドアプリ設定ライブラリを活用することで、デバイスレベルでの手動操作を必要とせずに、全デバイスにまたがる脆弱なサードパーティ製アプリケーションを更新できます。Iruのデバイス管理およびセキュリティ統合機能と組み合わせることで、単一のプラットフォームから脆弱性のコンテキストと是正ツールを利用し、適切な対応を行うことが可能です。

デバイス群に適した是正措置の実施頻度を選ぶ

適切な実施頻度は、組織のリスク許容度、コンプライアンス上の義務、および運用能力によって異なります。実用的な基準をいくつか挙げます：

• SOC 2 Type IIの対象となる組織は、通常、重大な脆弱性に対するパッチ適用を30日以内に行うことを約束しており、多くの監査人は現在、KEVに掲載されたCVEについては14日以内、あるいはそれ以上の迅速な対応を期待しています。
• FedRAMP Highでは、重大なCVEの是正を30日以内、高深刻度のCVEの是正を90日以内に行うことが求められます。
• CISコントロール7.4では、修正プロセスにおける人的遅延を削減するため、可能な限りパッチの自動展開を推奨しています。

現実的な制約はチームの対応能力です。500台のエンドポイントを管理する2人のITチームでは、毎週すべてのCVEを手動で追跡し、修正することは不可能です。自動化、明確なSLA階層、優先順位付けされたアクション項目を可視化するツールの活用こそが、小規模なチームが防御態勢を維持するための方法です。

プログラムの構築や改善を行う場合は、まずCISAのKEVリストから始め、優先順位付けのためにEPSSを導入し、Apple端末群のOSパッチ適用を自動化してください。この組み合わせにより、手作業の負担を最小限に抑えつつ、発生確率が高く、影響の大きい脆弱性に対処できます。

Apple製端末におけるCVEの公開から修正までのギャップを解消する準備はできていますか？デモをご依頼いただき、Iruの継続的なコンプライアンス管理と自動パッチ適用が実際にどのように機能するかをご確認ください。