「脆弱性の深刻度は『中』なので、次回の定期作業で対応します」

保守会社や社内の担当者から、このように説明されたら、何を確認するでしょうか。

深刻度の評価は、判断材料の一つです。しかし、その数字だけで、自社がいつまで対応を待てるかを決めることはできません。CVSSの基本評価値についても、策定団体のFIRSTは、脆弱性の深刻度を表すものであり、それだけでリスクを評価すべきではないと説明しています。

確認したいのは、自社の製品が影響を受けるのか、その機能へ外部からアクセスできるのか、実際の攻撃に使われているのか、悪用された場合にどの仕事へ影響するのか、という点です。

「脆弱性そのものの深刻度」と「自社が対応を急ぐべき度合い」を分けて考えることが、今回のテーマです。

前回は、設定変更を安全に進める方法と、失敗した場合の切り戻しを扱いました。今回は、その作業をいつ行うか、更新までに何をするか、対応の完了をどう判断するかを整理します。

本文の判断表、記入例、訓練の想定は、当事業所による実務上の提案です。公的機関が定めた一律の対応期限や、実在組織の内部手順を示すものではありません。

デジタル庁の事案を、「中だから放置した」と要約しない

デジタル庁は2026年9月11日、ガバメントソリューションサービス（GSS）への不正アクセスに伴う、職員等の個人情報の漏えいの可能性を公表しました。9月12日更新のQ&Aでは、VPN機器の脆弱性が悪用されたと説明しています。

同庁によると、悪用された脆弱性は、当初の評価が「中（Medium）」で、攻撃が確認される前に公表されていたものでした。深刻度に応じた一般的な対応よりも早く対処を進めたものの、修正プログラムの適用前に悪用されたとしています。

したがって、「中程度だったので対応せず放置したことが原因」と断定するのは適切ではありません。 具体的なCVE番号やCVSSの数値・版も、参照したQ&Aからは分かりません。

同Q&Aでは、修正プログラムの適用、関係アカウントの認証情報の変更、通信の遮断などを実施したと説明されています。現在も未修正のままという紹介にはしないでください。

この事案から自社の点検へつなげたいのは、当事者の内部判断を推測することではありません。公表された深刻度を、自社の利用状況と組み合わせて、対応へ結び付けられているかを確認することです。

CVSSは、「自社が被害に遭う確率」ではない

CVSSは、ソフトウェアなどの脆弱性の特性と深刻度を伝えるための仕組みです。例えばCVSS v4.0では、4.0～6.9が「Medium」に分類されます。これは、攻撃の成功率が40～69％という意味ではありません。

特に区別したいのが、製品の脆弱性情報などで示される基本評価値と、自社の環境を踏まえた判断です。

基本評価値は、脆弱性に固有の技術的な特性を表します。FIRSTは、これに脅威の状況や利用環境の分析を加える必要性を示しています。CVSS v4.0には、脅威や環境に関する評価項目も用意されています。

つまり、「CVSSの数字は役に立たない」ということではありません。何を表す数字なのかを理解し、数字が表していない自社の事情を補うという使い方が必要です。

社内の管理表でも、「公表されたCVSS」と「自社の対応優先度」は別の欄にしてください。

自社では緊急対応が必要だからといって、製品提供者が公表したCVSSの値を独自に書き換える必要はありません。元の評価を記録し、そのうえで「当社では外部公開中で、重要業務に影響するため優先対応」と判断の理由を残します。

また、数字を記録するときは、CVSSの版、評価した組織、確認した日付も併せて残すことをおすすめします。後から別の資料と比較するときに、同じ条件の評価かを確認するためです。

優先順位を付ける前に、「自社が対象か」を確認する

脆弱性の情報を受け取ったら、まず自社との関係を確認します。

同じメーカーの製品を使っていることだけで対象と決めるのでも、製品名が少し違うことだけで対象外と決めるのでもありません。製品名、型番、稼働中のバージョン、利用機能、構成などを、提供者の案内と照合してください。

IPAのガイドラインでも、IT資産の構成情報や更新状況を把握し、脆弱性情報と対応付けて管理する考え方が示されています。

例えば、保守会社から「昨年更新しました」と回答された場合、それだけでは、今回の脆弱性に対応しているか判断できません。

必要なのは、過去に更新作業をした事実だけではなく、現在何のバージョンが動いているか、そのバージョンが今回の影響範囲に入るかという確認です。

また、本社の一台だけでなく、支店、予備機、保守用の機器など、同じ製品を使っている場所を確認します。停止中の機器を、再利用するときの扱いも決めておくとよいでしょう。

確認結果は、少なくとも次の状態を区別して記録することを提案します。

「影響あり」「対象外を確認」「暫定対策中」「未確認」です。

「未確認」を「影響なし」と同じ扱いにしてはいけません。担当者が不在、管理情報が古い、委託先から回答がないといった場合は、確認する人と期限を決めます。

一方、対象外と判断した場合も、根拠を残してください。「当該製品を利用していない」「提供者が示す影響対象のバージョンではない」など、後から判断を確認できる形にします。

自社の対応を決めるために、五つの観点をそろえる

影響を受けることが分かったら、対応の優先度を判断します。

ここでは、深刻度の数字に加えて、次の五つを整理する方法を提案します。

確認する観点自社で確認する内容
影響を受ける条件対象の製品・バージョン・機能が実際に使われているか。攻撃に必要な条件が成立するか
悪用の状況提供者や公的機関などが、実際の悪用を確認しているか。自社で不審な動作を確認していないか
攻撃者が到達できる範囲インターネット、取引先との接続、社内端末など、どこから問題の機能へ到達できるか
悪用された場合の影響顧客情報、受注、会計、認証、バックアップなど、何が影響を受けるか
対処方法と残る制約修正版や回避策はあるか。停止や更新に何が必要か。対処までに何を制限できるか

この表は、各項目へ機械的に点数を付ければ、正解が出るというものではありません。判断に必要な情報を欠けたままにしないための確認表です。

特に、最後の「対処方法と残る制約」は、危険を小さく見積もるための欄ではありません。

「更新に時間がかかる」「作業費用が必要」という事情があっても、脆弱性を悪用される条件が変わるわけではありません。その事情を踏まえて、更新までの保護、利用の制限、代替手段を考えます。

また、「外部公開していない」だけで、対応不要とは決めないでください。どの接続や利用者から到達できるか、他のシステムとのつながりも確認します。

業務への影響についても、機器の価格だけでは判断しません。IPAは、情報の漏えい・改ざんや利用不能が、事業へ与える影響から重要度を判断する方法を示しています。

安価な機器でも、受注や管理者の接続に欠かせないなら、その役割を含めて評価しましょう。

「中」の機器を、「高」の機器より先に対処する場合もある

ここで、架空の会社に二つの対象が見つかった場合を考えます。

対象確認できている状況
A：深刻度「中」の脆弱性がある機器本番業務で利用中。問題の機能へインターネットから到達でき、提供者が実際の悪用を確認。顧客情報を扱う環境との接続がある
B：深刻度「高」の脆弱性があるソフトウェア検証専用環境で利用。外部からの到達を制限済みで、実顧客データはない。確認した情報では悪用の報告は見つかっていない

この条件であれば、Aについて、直ちに保護措置と修正の実施判断へ進む案が考えられます。Bにも対応期限を設けますが、数字が高いという理由だけで、Aの対応を待たせる必要はありません。

これは、AとBの条件を置いたうえでの判断例です。「中は高より先に対応する」という新しい固定ルールを作る話ではありません。

例えば、Bの接続制限が実際には効いていなかった、重要な認証情報が保存されていた、悪用が確認されたという情報が加われば、判断は変わります。

反対に、Aについて、問題となる機能を確実に停止できたなら、その効果を確認したうえで、修正までの進め方を再検討できます。

優先順位は、脆弱性に一度付けた順位を固定するものではなく、その時点で確認できた自社の状態に対する判断として管理してください。

CVSS・KEV・EPSSは、同じものを測っていない

優先順位を考える際には、CVSS以外の情報も利用できます。ただし、それぞれが何を示すかを分けて理解しましょう。

情報・指標主に分かること自社での使い方
CVSSの基本評価値脆弱性に固有の技術的な深刻度攻撃に必要な条件や、影響の性質を読む材料にする。
CISAのKEVカタログ実際の悪用が確認された脆弱性の情報自社に該当するものについて、対応の優先度を見直す材料にする。
FIRSTのEPSS公開された脆弱性が、今後30日間に実際の攻撃で悪用される確率の推定悪用可能性に関する補助情報として利用する。

特にEPSSは、自社の構成や業務上の損害まで評価するものではありません。FIRSTも、個別の組織の環境や対策、被害の大きさを含む完全なリスク評価ではないと説明しています。

したがって、EPSSの値を、そのまま「当社が被害に遭う確率」として経営者へ報告しないようにしてください。

また、EPSSには確率とは別に、他の脆弱性と比較した順位を表すパーセンタイルがあります。例えば「90パーセンタイル」は、悪用される確率が90％という意味ではありません。

運用上は、指標を一つ増やせば判断が完成するとは考えず、提供者の注意喚起、自社の構成、実際の記録と組み合わせます。

KEVに掲載が見つからないことや、予測値が低いことだけを理由に、他の悪用情報を無視するルールにはしないことをおすすめします。自社で不正アクセスの疑いがあるなら、予測の高低を待つ場面ではありません。

新しい情報が出たら、次の定例会議を待たずに再判断する

初めて脆弱性情報を確認したときと、数日後とでは、判断材料が変わる場合があります。

実際の悪用が報告される、影響するバージョンが訂正される、回避策が追加される、自社の別拠点にも対象製品があると分かる、といった場面です。

本記事では、こうした変化を、優先順位を見直す条件としてあらかじめ定めることを提案します。

直近では、JPCERT/CCが2026年10月8日に国内組織で相次ぐ不正アクセスへの注意喚起を公開し、翌9日に情報を追加しています。同資料では、従業員向けシステムや管理・運用側のツールも点検対象とし、影響を受ける製品の更新や、不要な機能の外部公開停止などを促しています。

この注意喚起を、GSSの事案と同一の侵入方法を示す資料として扱うわけではありません。公表された情報を一度読んで終わらせず、自社への影響を見直す必要がある例として取り上げています。

社内では、「新しい悪用情報を受け取った人が、誰へ連絡するか」「すでに決めた作業日を前倒しする権限は誰にあるか」を決めてください。

管理表には、最初に決めた優先度だけでなく、見直した日時と理由も残します。「なぜ対応日が変わったのか」を説明できるようにするためです。

期限は、「確認」「暫定対策」「修正完了」に分ける

対応期限を一つだけ設けると、何をいつまでに行うのかが曖昧になりがちです。

例えば、「金曜日までに対応」と書かれている場合、それは対象かどうかを調べる期限でしょうか。更新する日でしょうか。更新後の確認まで終える期限でしょうか。

ここでは、三つの期限を分ける方法を提案します。

一つ目は、自社への影響を確認する期限です。 対象の機器、稼働バージョン、問題となる機能の利用状況を確認し、対象・対象外・未確認を明らかにします。

二つ目は、暫定的な保護を判断・実施する期限です。 更新までの間に、利用制限や機能停止などが必要かを決め、実施した措置が機能しているかを確認します。

三つ目は、恒久的な対処と確認を終える期限です。 修正版の適用、製品の入替え、不要な機能の廃止など、自社が選んだ対処を完了させます。

すべての脆弱性について、三つの作業を同じ順番で行う必要はありません。確認でき次第、修正版を適用できる場合もあります。重要なのは、修正の日程を調整している間に、確認や暫定対策まで止まらないことです。

また、期限は「その日までは安全に待てる」という保証ではありません。

新しい悪用情報や自社の不審な動作があれば、期限前でも判断を見直します。確認期限までに情報がそろわなかった場合も、黙って次の日へ延ばさず、責任者へ状況を伝えてください。

「更新できない理由」と「残る危険への対応」を一組にする

更新できない理由がある場合は、その理由を具体化します。

「業務が止められない」という説明なら、どの業務が、どれくらい止められず、代替手段があるかを確認します。「保守会社の対応待ち」なら、何の回答や作業を待ち、いつまでに判断できるかを確認してください。

NISTのパッチ管理ガイドでは、通常の更新、緊急の更新、緊急の緩和措置、容易に更新できない資産への対応を分けて計画する考え方が示されています。

更新までの対処としては、提供者が示す回避策の適用、問題となる機能の停止、接続範囲の制限、機器の隔離などを検討します。ただし、どの対策が有効かは脆弱性と構成によって異なるため、提供者の情報や保守担当者の確認に基づいて選びます。

「多要素認証を使っている」「監視を増やした」といった対策名を、対象の脆弱性を回避できる根拠の代わりにしないでください。

確認したいのは、その措置によって、悪用に必要な条件をどう変えられるかです。

特に監視については、何を見つけられるか、見つけた後に誰が止めるかを整理します。記録を見る担当者を増やすことと、脆弱性を修正することは、同じ作業ではありません。

継続利用を認める場合は、業務責任者が、残る問題、暫定措置、利用条件、見直し期限を確認します。リスクを受け入れる判断をしたとしても、脆弱性そのものがなくなった扱いにはしません。

「更新予定」「適用済み」「確認済み」を分けて管理する

対処を決めた後は、完了の確認が必要です。

NISTは、修正プログラムについて、インストールできたことに加え、実際に有効になっていることを確認するよう示しています。

例えば、修正版を取得しただけなのか、配布したのか、適用したのか、必要な再起動や反映が終わったのかを分けます。

確認項目は製品に合わせて決めますが、現在稼働しているバージョン、提供者が示す対策条件、対象機器すべての処理結果を、記録で追えるようにしましょう。

二台構成の機器なら、片方だけを更新して全体を「完了」としないようにします。更新に失敗して以前の状態へ戻した場合も、「作業実施済み」ではあっても、脆弱性の対処完了とは区別します。

暫定措置を取った場合は、その措置が実際に効いているかを確認します。「設定を追加した」という記録だけでなく、意図した接続制限や機能停止になったことを確かめてください。

また、対象外と判断した場合も、その理由と確認日時を残します。構成を変えた際には、その判断が引き続き成り立つかを見直します。

確認のために、公開されている攻撃コードを本番環境へ無計画に実行する必要はありません。管理者や保守会社と、許可された範囲で、製品に適した確認方法を選んでください。

パッチの適用と、すでに侵入されていないかの確認は別

脆弱性への対応中に、不審な接続や身に覚えのない設定変更が見つかった場合は、更新作業だけで終えないようにしましょう。

ここでは、架空の状況を考えます。

脆弱性を使った侵入によって、通常とは別の管理者アカウントが作られていたとします。その後に入口となった脆弱性を修正しても、それだけで、追加されたアカウントまで削除されたとは判断できません。

これは、特定のGSSの侵入手口を説明したものではありません。脆弱性を直す作業と、侵入によって生じた変更を調べる作業の違いを示す例です。

不正アクセスの疑いがある場合は、社内の事故対応窓口へ連絡し、管理者や専門家と、被害拡大防止と必要な記録の保全を進めてください。IPAのガイドラインでも、インシデントの状況や対応経過を整理し、必要な証拠を保全する考え方が示されています。

「不正アクセスの証拠が見つかっていない」と報告するときも、どの期間の、どの記録を確認したかを添えましょう。

必要なログが残っていないことと、不正アクセスがなかったことは同じではありません。確認できなかった範囲は、未確認事項として扱います。

一方、該当製品を使っていたという理由だけで、すでに侵害されたと断定する必要もありません。確認できた事実に基づいて、調査と対処を進めることが重要です。

「脆弱性対応の判断票」で、理由と期限を残す

確認した情報は、連絡メールの中だけに散らばらないよう、一つの管理記録へまとめます。

次は、小規模な事業者でも使い始めやすい判断票の項目例です。新しい管理システムを購入することが前提ではなく、既存の台帳や作業管理表へ追加して構いません。

管理項目記録する内容
脆弱性の情報CVE番号や提供者の管理番号、公表資料、確認日時
公表された評価CVSSの値・版・評価元、後から変更があった場合の内容
自社の対象機器・サービスの管理番号、製品名、稼働バージョン、利用機能
影響判断の根拠対象・対象外・未確認の区分と、判断に使った資料や設定
悪用・接続状況悪用情報の有無、確認元、問題の機能へ到達できる範囲
業務への影響関係する情報・業務、停止や変更が必要な範囲
自社の対応方針優先度、判断理由、修正・制限・停止・入替えなどの方法
担当者と期限確認、暫定措置、恒久対処、完了確認の担当者と期限
暫定措置と残件実施内容、効果の確認、残る問題、継続利用の判断者
実施結果と再確認適用結果、現在の状態、確認の証跡、次に見直す条件

この判断票で重視したいのは、「優先度：高」とだけ書かないことです。

例えば、「本番環境で対象機能を外部公開しており、提供者が悪用を確認しているため、定期作業を待たずに対応する」と記録すれば、別の担当者も判断の理由を理解できます。

反対に、通常の保守日程で対応する場合も、何を確認したうえでその日程としたかを残します。

パスワード、秘密鍵、認証コードなどは判断票へ記載しません。調査記録や内部構成図も、必要な担当者だけが参照できる場所へ保管してください。

保守会社への依頼は、「対応してください」から一歩進める

外部へ保守を委託している場合は、誰が情報を集め、影響を判断し、作業を承認するかを決めます。

自社が技術的な確認をすべて行う必要はありません。ただし、保守会社からの「問題ありません」「対応予定です」という回答だけで、判断を終えないことをおすすめします。

例えば、次のように確認できます。

当社で利用している製品について、今回の脆弱性の影響有無と、その判断根拠をご提示ください。対象となる場合は、現在のバージョン、悪用情報、暫定措置、修正版の適用予定、適用後の確認方法を併せてご案内ください。未確認事項がある場合は、確認担当者と回答予定日もお知らせください。

これは依頼文の作成例です。契約上の管理範囲に合わせて調整してください。

併せて、定期保守に緊急の脆弱性対応が含まれるか、追加作業の承認が必要か、休日に誰へ連絡するかを確認します。事故が起きてから、契約範囲と連絡先の確認を始める状態を避けるためです。

自社の業務責任者は、停止による影響や代替業務を整理します。保守会社は、技術的な影響と対処方法を示します。両方の情報をそろえて、実施時期を決めてください。

「業務を止めたくない」という希望だけで延期するのでも、「技術的には更新できます」という説明だけで業務への影響を無視するのでもなく、必要な判断を分担することが大切です。

緊急対応に追われても、通常の更新を止め続けない

リスクに応じて優先順位を付けることは、急がないと判断した脆弱性を、期限なく残すための仕組みではありません。

IPAは、利用製品の脆弱性情報を継続して確認し、更新するとともに、製品選定時にはサポートの内容や期限も考慮するよう案内しています。

そこで、緊急対応のための連絡経路と、通常の更新を続ける日程を、両方用意しましょう。

例えば、定期作業で対応する対象には実施日を設定し、新しい悪用情報が出たら前倒しを判断します。更新できない製品については、隔離などの暫定措置だけでなく、入替えや利用終了の計画も管理します。

経営者へ報告する際も、全体の更新率だけを示すのではなく、重要な残件を別に示すことを提案します。

「更新済み95％」という数字だけでは、残る5％に、外部公開中の重要な機器が含まれるか分かりません。

確認したいのは、実際の悪用が報告されている対象が残っていないか、影響未確認のまま期限を超えていないか、暫定措置の期限が切れていないか、という点です。

多くの作業を終えたことと、先に対処すべき対象を残していないことを、分けて報告しましょう。

机上演習では、「中だから待つ」で判断が止まらないかを試す

運用が使えるかを確認するため、次のような架空の状況で話し合ってみてください。

保守会社から、利用中の通信機器に深刻度「中」の脆弱性があると連絡が入りました。修正版は提供されていますが、次の定期作業は二週間後です。対象機能が有効かは未確認で、その機器を止めると、一部の従業員が社外から業務システムへ接続できなくなります。

この段階で、誰が機能の利用状況を確認するでしょうか。確認できるまで、どの接続を認めるでしょうか。停止した場合の業務を、誰が整理するでしょうか。

続いて、「提供者が実際の悪用を確認した」「支店にも同じ機器があると分かった」という条件を追加します。

最初の作業日程を見直せるか。関係する機器を追加で確認できるか。保守会社の回答待ちで止まらず、判断する責任者へ連絡できるかを確かめてください。

さらに、「修正版を適用したが、一台だけ反映結果を確認できない」という条件を置けば、完了報告の作り方も確認できます。

演習の目的は、参加者に特定の結論を言わせることではありません。必要な情報を集め、未確認事項を残したまま安全と決めず、判断理由と期限を共有できるかを見ることです。

実際の機器へ攻撃を試したり、本番業務を止めたりする必要はありません。架空の情報と、実際の連絡先・役割分担を組み合わせて確認できます。

まとめ――深刻度の数字を、具体的な対応へつなげる

脆弱性への対応では、公表された深刻度を確認するだけでなく、自社が影響を受ける条件、悪用の状況、接続範囲、業務への影響を組み合わせて判断しましょう。

そのうえで、誰が確認し、更新までに何を制限し、いつ対処を完了させるかを決めます。修正版を適用した後も、実際に反映されたことを確認し、不正アクセスの疑いがあれば別に調査します。

最初の一歩は、現在対応待ちになっている脆弱性を一つ選び、次の説明ができるかを確かめることです。

なぜその優先度なのか。何を根拠にその日程を選んだのか。待っている間は何をしているのか。新しい情報が出たら、誰が判断を変えるのか。

「深刻度が中なので、後で対応します」から、「自社への影響を確認し、この理由で、この期限までに対処します」へ。

必要なのは、すべてを同じ緊急度で扱うことではありません。先に守るべき対象を見極めながら、残った対処も期限なく放置しない運用です。

ライトハウスコンサルタントでは、パソコン、クラウド、アカウント、社内ルールの現状確認と、対策の優先順位の整理を支援しています。保守会社から届く脆弱性情報を、自社の判断や対応計画へつなげたい場合は、ご相談ください。

投稿タグ
, , , , , , , , , , , , ,