AI時代のリスクベース脆弱性管理 ― 限られたリソースを本当に危険な脆弱性へ集中する ―

前回の記事 では、AI時代には攻撃者による脆弱性の分析や攻撃コードの作成が高速化し、「脆弱性公開から攻撃までの時間」が短縮される可能性について説明しました。そのため、すべての脆弱性を同じ優先順位で対応する従来の考え方ではなく、攻撃されるリスクが高い脆弱性から優先的に対応する「リスクベース脆弱性管理」への転換が重要になります。

しかし、「リスクベースで対応する」と言われても、具体的にどのように優先順位を決め、どのように運用すればよいのでしょうか。本稿では、実際の運用を想定したリスクベース脆弱性管理の考え方について紹介します。

目次

なぜCVSSだけによる基準では十分でないのか

多くの企業では、CVSS（Common Vulnerability Scoring System）のスコアを基にパッチ適用の基準を決めています。例えば、「CVSS 9.0以上の脆弱性は1ヶ月以内にパッチを適用する」などです。実際に脆弱性対応業務にあたっている方はわかると思いますが、CVSS 9.0以上の脆弱性は、大量に発生しています。Windowsであれば毎月そのような脆弱性がありますし、Webサーバの代表的な製品であるOracle WebLogic Serverもほぼ毎回、そのような脆弱性が出ています。基準通りに全ての機器にパッチを適用することは現実的でなく、未適用機器が相応に発生します。さらにAIを活用した脆弱性検出が広がる中、脆弱性の公表件数は急増を始めています。

パッチ適用機器の割合や未適用機器の数は、自社のリスクを直接表すものなのでしょうか？確かにアバウトには表していると言えますが、事業継続に直結する指標でしょうか？

例えば、同じCVSS 9.8の脆弱性であっても、インターネットから直接アクセス可能なWebサーバと、ネットワーク内からしかアクセスできないサーバでは、実際に攻撃を受ける可能性は大きく異なります。また、認証基盤や業務システムなどの重要システムと、そうでないシステムでは、事業への影響が大きく異なります。

また、期限についても「1ヶ月以内」や「14日以内」でいいのでしょうか？ AI時代には、攻撃者が短期間で攻撃を開始するケースも増えると考えられます。そのため、CVSSだけではなく、システム環境や攻撃者の動向を踏まえ、危険なものを優先して対応することが必要になるのです。

リスクベースで優先度を決定する

本稿で紹介するリスクベース脆弱性管理では、脆弱性そのものの深刻度に加え、自社の環境と攻撃者の動向を考慮して優先度を決定します。

評価項目としては、CVSSに加え、システムの公開状況（System Exposure）と攻撃の発生状況（Exploitation）を組み合わせます。

System Exposureとは、攻撃を受けるプロトコルやサービス、機能がどの程度、外部から到達可能な状態にあるかを評価する考え方です。例えば、インターネットから直接到達可能なシステムは「Open」、プロキシやFWなどによって一定のアクセス制御下にあるものは「Controlled」、分離されたネットワークにあるものは「Small」といったように分類します。

Exploitation状況は、技術情報やPoCが公開されている段階と攻撃が確認された段階の2段に分けることができます。しかしながら、AI時代には、この二つ段階の時間的な差はほとんどなくなると思われます。ですので、Exploitation状況は、有無というシンプルな区分で、技術情報やPoCの公開も「有」と評価する方法が適切ではないでしょうか？

以下に具体的な優先度の例をあげます。

この優先度ですが、システムの重要度によって分けることも考えられます。

米国もリスクベース運用へ転換している

前回の記事でも触れましたが、米国においても、2026年6月、米国サイバーセキュリティ・社会基盤安全保障庁（CISA）が、新たな指令「Binding Operational Directive（BOD）26-04 BOD 26-04: Prioritizing Security Updates Based on Risk」を公表し、連邦政府機関に対する脆弱性対応の考え方を大きく見直しました。本指令では、システムの公開状況や攻撃可能性、実際の悪用状況など、複数の要素を組み合わせて対応期限を決定しています。

これは、「すべての脆弱性を一律に修正する」のではなく、「攻撃される可能性が高く、影響が大きい脆弱性へ限られたリソースを集中させる」という考え方を運用ルールとして具体化したものと言えます。

現場で適用条件を確認する

脆弱性情報には、対象となる製品やバージョンだけでなく、「特定の機能が有効であること」「特定の設定になっていること」など、脆弱性が成立する条件が記載されているケースも少なくありません。つまり、製品名やバージョンが一致していても、実際には脆弱性の影響を受けない場合があります。

しかし、このような適用条件は、システムの構成や設定を把握している現場でなければ判断できないことも少なくありません。そのため、実務上は、セキュリティ部門では適用条件を満たしているものとして一次優先度を決定し、その後、現場部門が構成や設定を確認した結果、条件に合致しないことが確認できた場合には、優先順位を見直す運用が望ましいと考えます。

このようなワークフローを採用することで、見落としを防ぎながら、実際には影響を受けない脆弱性への対応工数を削減し、よりリスクの高い脆弱性へリソースを集中させることができます。

攻撃情報を継続的に収集し反映する

一方で、攻撃者の状況は日々変化しており、脆弱性情報が公表された時点では攻撃事例がなくても、その後、攻撃コードの公開や実際の悪用が確認されるケースがあります。

そのため、Known Exploited Vulnerabilities（KEV）や攻撃コード（PoC）の公開状況、脅威インテリジェンスなどを継続的に確認し、必要に応じて優先順位を引き上げることも必要です。

つまり、リスクベース脆弱性管理とは、一度優先順位を決めて終わるものではありません。攻撃情報や環境の変化を踏まえながら、継続的に優先順位を見直していく運用が求められます。

リスクベース脆弱性管理のワークフロー

以上を踏まえると、リスクベース脆弱性管理は次のような流れになります。

まず、CVSSとSystem Exposure、Exploitation状況から一次優先度を決定します。その後、現場部門が適用条件を確認し、脆弱性が成立しないことが確認できれば優先順位を見直します。一方で、PoCの公開や攻撃の確認など、新たな脅威情報が得られた場合には、優先順位を引き上げます。

このように、現場確認によって優先順位を下げる仕組みと、脅威インテリジェンスによって優先順位を上げる仕組みの両方を組み込むことで、限られたリソースを真に対応すべき脆弱性へ集中させることができます。

おわりに

AI時代には、攻撃者の活動が高速化することで、防御側に残された時間はますます短くなっていきます。その中で、すべての脆弱性へ同じように対応することは現実的ではありません。

重要なのは、「どの脆弱性から対応するか」を継続的に判断できる仕組みを構築することです。

リスクベース脆弱性管理とは、単に評価方法を変えることではありません。セキュリティ部門、システム運用部門、そして脅威インテリジェンスを連携させながら、状況変化に応じて優先順位を継続的に見直す運用そのものです。

AI時代に求められる脆弱性管理とは、こうした運用を組織として定着させることではないでしょうか。