リスクベースで見極める脆弱性対応の優先順位～フロンティアAI時代の脆弱性管理（3）

フロンティアAI時代には、「侵入され得ることを前提とした多層防御」「早期検知」「脆弱性管理の徹底」を、AI時代のスピードに合わせて高度化することが不可欠です。本連載では、その中でも特に重要な「脆弱性管理」に焦点を当て、組織のセキュリティ推進部門や担当者が押さえるべき5つのポイントを解説しています。

実際に2026年7月以降、国内では個人情報漏えいが相次いでおり、Webシステムやスマートフォンアプリに起因するものも少なくありません。ラックの分析でも、Webアプリケーションの脆弱性悪用や認証情報の窃取、APIの悪用など複数の侵入経路が確認されており、外部公開資産全体を継続的に把握・是正することの重要性が高まっています。現時点で、国内の一連の事案にAIエージェントが直接関与したという公開証拠はありませんが、海外ではAIを活用した低コスト攻撃の実例が確認されています。こうした状況を踏まえ、連載第3回では、フロンティアAI時代の脆弱性管理を見据え、リスクベースで評価し対応する際の基本的な考え方について解説します。

フロンティアAI時代のリスクベース評価

リスクベース評価の考え方と、優先順位付けや対応期限を判断する際のポイントについて解説します。

リスクベース評価とは

リスクベースで脆弱性対応の優先順位を判断する考え方は、以前から脆弱性管理において重要とされてきましたが、フロンティアAIによる脆弱性発見能力の向上が議論される中、改めてリスクベースでの脆弱性評価に注目が集まり、既存の評価基準や運用を見直す組織が増えています。

ラックが支援するお客様の中でも、「フロンティアAIを踏まえて評価の軸を変えるかどうか」の議論が行われているケースがあります。このような見直しが求められる背景には、フロンティアAIにより、これまで見逃されていた脆弱性が発見されやすくなり、組織が対応すべき脆弱性の数の増加が懸念されていることがあります。限られたリソースを影響の大きい脆弱性へ集中させることが重要です。

リスクベースの脆弱性評価とは、脆弱性そのものの深刻度（CVSS基本値）だけでなく、実際の悪用可能性やビジネスへの影響を考慮して脆弱性のリスクを評価する考え方です。具体的には、以下の4つの要素を考慮します。

• 脆弱性そのものの深刻度
• 脆弱性の悪用状況
• システムの公開状況
• 資産の重要度

これらの要素を基に評価した結果は、対策の優先順位付けや対応期限の判断に活用します。

対策優先度付け・期限設定

リスクベース評価の結果を用いて対策の優先順位付けや対応期限の判断をするためには、あらかじめ組織内でルールを定める必要があります。対応判断のばらつきを抑え、影響の大きい脆弱性へ限られたリソースを集中しやすくするためです。

ルールを検討する際には、BOD 26-04やSSVCなどの既存の評価指標やフレームワークが参考になります。ただし、それらをそのまま適用するのではなく、自組織のシステム構成や業務影響、対応体制に合わせて、リスク評価の基準、対策の優先順位、対応期限を定めることが重要です。

参考となる考え方やフレームワーク

ここでは、自組織に合ったルールを検討する際に参考となる考え方やフレームワークを紹介します。いずれもそのまま適用するのではなく、自組織の状況に応じて評価基準や対応ルールを設計するための参考として捉えることが重要です。

BOD 26-04

BOD 26-04（Prioritizing Security Updates Based on Risk）^※1は、米国のCISAが連邦政府機関向けに示した、リスクに基づくセキュリティ更新の優先順位付けの考え方をまとめた指令です。脆弱性の深刻度に加え、「対象資産がインターネットから到達可能か」「既に悪用が確認されているか」「攻撃が自動化されているか」「悪用された場合の技術的影響がどの程度か」といった4つの観点を踏まえ、対応の緊急度や期限を判断する点が特徴です。

なお、「既に悪用が確認されているか」については、CISAが公開するKEV（Known Exploited Vulnerabilities）カタログを用いて判断することが示されています。

※1 BOD 26-04: Prioritizing Security Updates Based on Risk | CISA

SSVC

SSVC（Stakeholder-Specific Vulnerability Categorization）^※2は、脆弱性の深刻度だけでなく、実際の悪用状況やシステムへの影響などを踏まえて、対応優先度を判断するためのフレームワークです。製品開発者やシステム運用者など、立場ごとに判断モデルが用意されており、それぞれの意思決定を支援することを目的としています。

SSVCでは、「実際に悪用されているか」「対象システムがどの程度外部から到達可能か」「攻撃を自動化できるか」「悪用された場合に人や業務へどの程度影響があるか」などの観点を組み合わせ、対応を急ぐべきか、通常計画で進めるかなどの判断につなげる点が特徴です。

※2 Stakeholder-Specific Vulnerability Categorization (SSVC) | CISA

4つの要素

リスクベース評価で優先順位を判断する際に考慮したい4つの観点を整理します。

①脆弱性そのものの深刻度

脆弱性そのものの深刻度を評価する際は、CVSS基本値（Base Score）が参考になります。CVSS基本値は複数の評価項目から構成されています。通常はCVSS基本値のスコアを初期判断の目安として用いますが、対応を急ぐ可能性がある脆弱性では、評価項目の内訳も確認するとより深く内容を把握できます。

攻撃元区分、攻撃条件の複雑さ、必要な特権レベル、利用者の関与などを見ることで、攻撃が成立する条件を把握しやすくなり、影響範囲の確認や対策計画の検討に役立ちます。なお、「CVSS基本値7.0以上」を対応の要否を決める要素の1つに活用している組織が比較的多く見受けられます。

②脆弱性の悪用状況

脆弱性の悪用状況を把握する際は、KEVやEPSSが参考になります。KEVは実際の攻撃で悪用が確認された脆弱性を一覧化したもので、最近では掲載有無を脆弱性評価の要素の1つとして取り入れる組織も増えています。EPSSは、今後30日以内に攻撃で悪用される可能性をスコア化した指標で、KEVと合わせて主要な脆弱性スキャナの評価指標に取り入れられている場合があります。

より詳細に悪用状況を確認したい場合は、攻撃コードやPoCの公開有無に加え、その内容の信頼性や実際の利用状況も確認するとよいでしょう。調査にはGitHubやSNS、セキュリティベンダーのレポート、ソフトウェアベンダーのアドバイザリなどが活用できます。昨今は、攻撃コードやPoCの検証動画などが公開されているケースもあります。

③システムの公開状況

システムの公開状況は、脆弱性の対応優先度を判断するうえで重要な観点です。一般的に、インターネットからアクセス可能な外部公開資産は攻撃対象となりやすいため、優先的に対応を検討する必要があります。一方で、BtoB向けシステムやVPN・専用線経由でのみ利用できるシステム、社内限定システムなどは、利用者やアクセス経路が一定程度限定されることから、その利用形態も踏まえて対応優先度を判断することが重要です。

こうした公開状況は、平時から資産管理台帳などに整理しておくことが望ましいです。システムの公開状況を十分に把握できていない場合は、組織の保有するIPアドレスレンジに脆弱性スキャナなどを用いて一斉にスキャンを行うことも手段の1つです。

④資産の重要度

資産の重要度を把握する際は、CIA（機密性・完全性・可用性）の観点で整理すると分かりやすくなります。資産管理台帳などで資産重要度が定義されている場合は、その評価結果を活用すると効率的です。重要度が定義されていない場合は、以下のような観点を基に評価することで、自組織にとって影響の大きい資産を把握しやすくなります。

• 利用者数や利用頻度
• 取り扱うデータの重要度
• 業務停止時の事業影響
• 法令や契約への影響
• 他システムへの影響範囲や依存関係

4つの要素を用いた評価フローと対応基準

ここでは、前述した4つの要素を用いて脆弱性を評価し、対策の優先度や対応期限を判断する方法の一例を記載します。なお、実際には自組織のシステム構成や運用体制に合わせて評価基準や対応期限を検討する必要があります。記載された対応レベルや対応期限等は、考え方を分かりやすく示すための参考例であるため、実際の基準は許容可能なリスクや対応体制を踏まえて組織ごとに定めることが重要です。

対応フロー例

実際にご支援したお客様では、フロンティアAI時代を見据え、「判断をより精緻にするためにルールを増やす」ことが、かえって対応の遅れにつながる場合もあることから、評価基準をあらかじめ定義し、優先度判定の一部を機械的に行うことで、個別判断を最小限に抑える取り組みを進めている組織もあります。

以降では、図の流れに沿って、平時の準備から脆弱性公開後の評価、対応レベルの決定、システム担当者による影響確認、対策実施までの流れを説明します。

①「システム重要度」を整理

脆弱性が公開された際に迅速に対応するため、平時から各システムの公開状況や資産重要度を資産管理台帳などに整理しておきます。なお、この情報については、定期的に棚卸を行うことが望ましいです。

②「脆弱性の危険度」を判断

脆弱性が公開された場合、まずはCVSS基本値、KEVへの掲載有無、必要に応じて攻撃コード・PoCの公開状況などを確認し、脆弱性そのものの深刻度や悪用状況を把握します。その結果を脆弱性危険度の判断表に当てはめ、脆弱性の危険度を判断します。

③「対応レベル」を判断

①「システム重要度」と②「脆弱性の危険度」をマトリックス表に当てはめ、システムごとの対応レベルを算出します。

④「影響・対応期限」を確認

各システム担当者は、自システムが該当する脆弱性の影響を受けるかを確認し、影響を受ける場合は、対応レベルを基に対応期限を確認します。

⑤対策の実施

影響を受けることが確認された脆弱性については、対応レベルごとに定めた期限までに、修正やアップデートを実施します。残存リスクがあればそちらを整理・可視化し、リスクをコントロールにつなげます。

なお、緊急性の高い問題点について、すぐさまアップデートといった根本対策が行えない場合は、ベンダーからの公開情報等で案内された緩和策や、すでにWAFやIPS等のセキュリティ対策製品を導入されている場合はそれらを用いた暫定策を検討する必要があります。それらを用いた対策も行えず、システムに重大な影響を及ぼす可能性がある場合は、システムを停止する選択肢も視野に入れる必要があります。そのようなケースに備え、平時にシステム停止の判断基準も策定しておくことが重要です。

さいごに

フロンティアAI時代への対応は、従来の脆弱性管理の考え方も活かしながら、より迅速かつ効率的に運用できるよう見直していくことが重要です。まだ評価基準を整備していない組織は、自組織の環境に応じた基準の策定から取り組んでみましょう。

一方で、既にリスクベース評価を導入している組織も、現在の評価軸や運用ルールがフロンティアAI時代においても有効であるかを確認します。判断に時間がかかる部分があれば、評価基準の整理や一次判定の自動化など、運用そのものを必要に応じて見直しましょう。

今回紹介した評価フローを自組織のシステム構成や運用体制に合わせて調整することで、実運用に落とし込めます。情報収集や一次判定など、機械的に処理できる部分の自動化も視野に入れることで、運用負荷を抑えながら、より迅速かつ継続的な脆弱性対応につなげることができます。

プロフィール