「重大な脆弱性が公表されました。対応が必要です」——この報告を受けたとき、経営者が判断できなければ、その判断は報告した人に委ねられます。 委ねること自体が悪いわけではありません。問題は、費用や業務停止を伴う判断まで委ねてしまい、後から「なぜあのとき止めたのか」「なぜ止めなかったのか」を検証できなくなることです。
本記事は、技術者になるためのものではありません。ベンダーや情シスから上がってくる報告を読んで、自分で優先順位を判断できるようになるための最小知識に絞って整理します。用語の暗記は不要で、必要なのは「何を確認すれば判断できるか」を知っておくことです。
目次
- 結論：脆弱性は「弱点」であって「故障」ではない
- バグとの違い
- CVE番号とは
- CVSSスコアとは、そしてスコアだけで決めてはいけない理由
- スコアより優先すべき3つの判断材料
- 報告を受けた経営者が確認する4つの質問
- パッチを当てれば終わりではない場合がある
- 自社に情シスがいない場合の現実的な備え
- よくある誤解
- 確認チェックリスト
- よくある質問（FAQ）
- 判断に迷ったら
<a id="conclusion"></a>
結論：脆弱性は「弱点」であって「故障」ではない
脆弱性とは、悪用されると本来できないはずのことができてしまう、ソフトウェアや設定の弱点です。ここで大事なのは、脆弱性がある状態でもシステムは正常に動くということです。壊れていないので、業務からは見えません。
この「見えない」という性質が、経営判断を難しくします。壊れていれば直す判断は簡単ですが、動いているものを止めて更新する判断には、必ず「本当に今必要か」という問いが伴います。そしてこの問いに答えるには、危険度と自社への当てはまり方を切り分けて考える必要があります。
先に結論を言うと、判断の順序は次の3段階です。
- 自社に当てはまるか（その製品・バージョンを使っているか）
- 攻撃者から届く場所にあるか（インターネットに面しているか、社内だけか）
- すでに悪用されているか（実際の攻撃が観測されているか）
この3つが揃って「はい」なら最優先です。逆に、危険度が最高でも自社が使っていなければ対応は不要です。危険度の数字は、この3段階の後に見るものであって、最初に見るものではありません。
<a id="bug"></a>
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
バグとの違い
混同されがちですが、実務では区別できたほうが判断が速くなります。
横にスクロールして確認できます
| バグ（不具合） | 脆弱性 | |
|---|---|---|
| 現れ方 | 動作がおかしい、止まる | 正常に動いているように見える |
| 気づく人 | 利用者、運用担当 | 研究者、攻撃者、メーカー |
| 困る相手 | 自社の業務 | 自社と、その先の取引先・顧客 |
| 放置したときの進み方 | 業務が回らないので必ず対処される | 誰も困らないので放置されがち |
「困る人が現れないから放置される」——これが脆弱性の最大の厄介さです。バグは現場から声が上がりますが、脆弱性は誰も困らないまま数年放置され、ある日突然、被害という形で表面化します。
したがって組織として必要なのは、技術力よりも**「誰も困っていないのに定期的に確認する仕組み」**です。仕組みがなければ、忙しい月は必ず後回しになります。
<a id="cve"></a>
CVE番号とは
報告書に必ず出てくる「CVE-2026-◯◯◯◯」という記号は、個々の脆弱性に付けられた世界共通の管理番号です。同じ弱点が各社バラバラの名前で呼ばれると話が通じないため、共通の番号を振って識別できるようにしています。
経営者にとっての実用的な意味は3つです。
- この番号で会話が成立する。 販売店や保守委託先に「CVE-2026-◯◯◯◯の影響を受けますか」と聞けば、調べるべき対象が一意に決まります。「例のセキュリティの問題」より圧倒的に速い。
- 番号があれば公開情報を追える。 日本語ではJVN（Japan Vulnerability Notes）、IPAの脆弱性対策情報で確認できます。
- 番号がない報告は要注意。 「重大な脆弱性が見つかりました」とだけ言われて番号が示されない場合、出所が曖昧な情報か、営業目的の可能性があります。まず番号を聞いてください。
<a id="cvss"></a>
CVSSスコアとは、そしてスコアだけで決めてはいけない理由
CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を0.0〜10.0の数値で表す共通の評価方法です。仕様はFIRSTが公開しており、一般に9.0以上が「緊急」、7.0以上が「重要」といった区分で語られます。
数値があると判断しやすく見えますが、このスコアだけで優先順位を決めるのは誤りです。 理由は2つあります。
理由1：CVSSの基本値は「一般的な条件での深刻度」であって、自社の状況を含んでいない。 同じスコア9.8でも、インターネットに公開しているサーバーと、社内の閉じた環境でしか使っていない機器では、自社にとっての緊急度がまったく違います。スコアは自社の構成を知りません。
理由2：スコアが中程度でも、実際に悪用されているなら緊急。 攻撃者は必ずしも最高スコアの脆弱性を狙うわけではなく、攻撃しやすく、対象が多いものを選びます。「CVSS 6点台だが実際の攻撃が観測されている」ほうが、「CVSS 9点台だが攻撃手法が確立していない」より危険なことは普通にあります。
つまりスコアは、判断材料の一つであって、判断そのものではありません。「9.8だから今すぐ」「5.8だから来月」という運用をしている組織は、優先順位を機械的に付けているだけで、リスクに基づいて判断してはいません。
<a id="priority"></a>
スコアより優先すべき3つの判断材料
実務で優先順位を決めるとき、スコアより先に見るべきものがあります。
材料1：自社が影響を受けるか。 対象の製品を使っているか、そのバージョンか、その機能を有効にしているか。ここで「使っていない」が確定すれば、以降の検討は不要です。 判定できない場合、問題は脆弱性ではなく資産管理の不備なので、そちらを先に直す必要があります。
材料2：攻撃者から届く場所にあるか。 インターネットから直接アクセスできる機器・サービスは最優先です。社内ネットワークの奥にあるものは、外部から直接は狙われにくい。ただし「社内だから安全」ではなく、一度侵入された後の横展開に使われるため、順序が後になるだけです。
材料3：すでに悪用されているか。 実際の攻撃が観測されている脆弱性は、理論上の危険度に関わらず優先されます。米国CISAが公開している「悪用が確認された脆弱性カタログ（KEV）」は、この判断の代表的な材料として広く参照されています。日本企業に法的義務が生じるわけではありませんが、「実際に悪用されていると政府機関が認定した」という事実は、社内で優先度を説明するときの根拠になります。
この3つを確認したうえで、同じ条件のものが複数あればスコアで並べる——これが実務の順序です。
<a id="questions"></a>
報告を受けた経営者が確認する4つの質問
ベンダーや情シスから「脆弱性が公表されました」と報告を受けたとき、次の4つを聞いてください。技術的な知識がなくても、答えの質で状況が分かります。
質問1：「弊社は影響を受けますか。判断の根拠は何ですか。」 「たぶん大丈夫」「おそらく影響ありません」という回答は、確認していない可能性があります。使用製品とバージョンを照合した結果として答えられているかを見てください。
質問2：「その機器・サービスは、外部から直接アクセスできますか。」 外部公開の有無で緊急度が変わります。即答できないなら、資産の把握ができていないサインです。
質問3：「すでに悪用されている報告はありますか。」 公表されているかどうかで、様子を見る余地があるかが変わります。
質問4：「対応にかかる時間と、業務への影響を教えてください。」 更新のために業務を止める必要があるのか、夜間で済むのか。ここが経営判断の対象です。技術的な是非ではなく、いつ止めるかを決めるのが経営の役割です。
この4問に具体で答えが返ってくる相手は、実際に調べています。抽象的な安心の言葉だけが返ってくる場合は、もう一段掘ってください。
<a id="after"></a>
パッチを当てれば終わりではない場合がある
多くの脆弱性は、修正プログラム（パッチ）を適用すれば対応完了です。ただし一部には、パッチを当てただけでは終わらない種類があります。
代表的なのは、パッチ適用前にすでに侵入されていた可能性がある場合です。攻撃者が認証情報や内部の鍵を盗んでいた場合、パッチで穴を塞いでも、盗んだ鍵で正規の利用者として入り直せます。この場合は、パッチに加えて認証情報の再発行や、侵害の有無の調査が必要になります。
したがって、悪用が確認されている脆弱性については、報告を受けたときにもう1問追加してください。
「パッチ適用のほかに、認証情報の入れ替えや侵害調査は必要ですか。」
この質問に「必要かどうかを確認します」と返ってくるのは正しい対応です。「パッチを当てたので大丈夫です」と即答される場合、そのリスクを検討していない可能性があります。実際に侵害が疑われる状況であれば、インシデント対応支援のように外部の手を早く入れたほうが、被害の確定が速くなります。
<a id="nosec"></a>
自社に情シスがいない場合の現実的な備え
専任者がいない企業で、脆弱性情報を毎日追うのは現実的ではありません。追わなくても機能する備えを、優先度順に挙げます。
備え1：何を使っているかの一覧を持つ。 最も費用対効果が高いのがこれです。サーバー、ネットワーク機器、業務システム、クラウドサービス、そして複合機やカメラなどIT資産として管理されていない機器。一覧があれば、脆弱性が公表されたときに「自社が対象か」を数分で判定できます。無ければ、毎回問い合わせて待つことになります。
備え2：自動更新にできるものは自動更新にする。 判断が要らないものを減らすのが、専任者不在の組織では最も効きます。
備え3：連絡先を決めておく。 販売店・保守委託先・クラウド事業者のうち、「この製品はここに聞く」を一覧に併記しておきます。事故のときに探し始めるのでは遅い。
備え4：外部に月次で見てもらう。 毎日追うのは無理でも、月に一度まとめて確認する仕組みなら回ります。セキュリティ運用伴走のような形で外部に持たせる選択肢もあります。
備え1だけでも実施すれば、緊急時の初動は大きく変わります。製品を買う前に、一覧を作るほうが先です。
<a id="misunderstanding"></a>
よくある誤解
- 「うちは小さいから狙われない」。 攻撃の多くは対象を選ばず、条件に合う機器を自動的に探して行われます。規模は防御になりません。
- 「スコアが低いから後回しでよい」。 悪用状況と外部公開の有無のほうが、スコアより優先されます。
- 「パッチを当てたから完了」。 侵入後に盗まれた認証情報は、パッチでは無効化されません。
- 「社内システムだから関係ない」。 侵入後の横展開に使われるため、順序が後になるだけで対象ではあります。
- 「ベンダーが管理してくれているはず」。 契約に脆弱性対応が含まれていなければ、誰も見ていない可能性があります。契約書を確認してください。
- 「脆弱性が公表された＝すぐ被害が出る」。 必ずしもそうではありません。慌てて業務を止めるより、影響有無を確認してから判断するほうが損失は小さい。
<a id="checklist"></a>
確認チェックリスト
- 報告にCVE番号が含まれているか確認した
- 自社が影響を受けるかを、製品とバージョンの照合で確認した
- その機器・サービスが外部から直接アクセスできるかを確認した
- すでに悪用されている報告があるかを確認した
- 対応にかかる時間と業務への影響を確認した
- 悪用済みの場合、認証情報の入れ替えと侵害調査の要否を確認した
- 自社のIT資産一覧（複合機・カメラ等の非管理機器を含む）がある
- 製品ごとの問い合わせ先を一覧に併記してある
- 自動更新にできるものは自動更新にしてある
- 保守契約に脆弱性対応が含まれるかを確認した
<a id="faq"></a>
よくある質問（FAQ）
Q. 脆弱性とバグは何が違うのですか。 A. バグは動作の不具合で、業務が回らないため必ず対処されます。脆弱性は正常に動いているように見える弱点で、誰も困らないまま放置されやすい点が決定的に違います。
Q. CVSSスコアがいくつ以上なら対応すべきですか。 A. 数値だけで線を引くのは適切ではありません。順序としては、①自社が影響を受けるか、②外部から届く場所にあるか、③すでに悪用されているか、を確認し、同条件のものが複数あるときにスコアで並べます。
Q. すべての脆弱性に対応しなければなりませんか。 A. いいえ。自社が使っていない製品の脆弱性は対応不要です。まず影響有無の判定が先で、そのためにIT資産の一覧が必要になります。
Q. 情シスがいません。何から始めればよいですか。 A. IT資産の一覧作成です。何を使っているか分からない状態では、脆弱性が公表されるたびに判断できません。一覧があるだけで、緊急時の初動が数日単位で変わります。
Q. 「対応します」と言われましたが、いつまでに終わるか聞くべきですか。 A. 聞くべきです。期限のない対応は着手されないまま流れます。「いつまでに、影響有無の回答をもらえるか」を先に確定させ、その後で修正の期限を決めるのが現実的です。
Q. 業務を止めてまで更新すべきですか。 A. 外部公開されており、かつ悪用が確認されている場合は、止めてでも優先する価値があります。そうでなければ、通常の保守枠に載せる判断も合理的です。この判断こそが経営の役割で、技術側に委ねる部分ではありません。
Q. 保守契約があれば安心ですか。 A. 契約内容によります。「不具合対応」と「脆弱性対応」は別物として扱われることがあり、後者が含まれていない契約は珍しくありません。契約書の記載を確認してください。
<a id="cta"></a>
判断に迷ったら
脆弱性の報告を受けたときに経営者がすべきなのは、技術的な正誤の判断ではありません。影響有無・外部公開・悪用状況の3点を確認させ、いつ業務を止めるかを決めることです。この3点を聞ける状態になれば、報告の質も自然に上がります。
そして最も効くのは、報告を受ける前の準備です。自社が何を使っているかの一覧があるかどうかで、初動の速さは決定的に変わります。製品を買う前に、一覧を作るほうが先です。
GXOは特定のセキュリティ製品の販売元ではないため、「今ある契約と仕組みで足りる部分」と「投資が必要な部分」を分けて整理できます。
- 何から手をつけるか、資産の棚卸しから相談したい → セキュリティ事業
- 月次で見てもらう体制を作りたい → セキュリティ運用伴走
- 侵害が疑われる状況にある → インシデント対応支援
- 取引先から体制の提出を求められている → ISMSの情報セキュリティ方針の作り方
- 自社のIT・DXの現在地から把握したい → DX成熟度診断
「スコアが高いから急ぐ」ではなく「自社に届くから急ぐ」。その判断軸の整理から、ご一緒します。
参考（一次ソース）
- JVN（Japan Vulnerability Notes）（一次・JPCERT/CCとIPAが共同運営する脆弱性情報ポータル）
- IPA「脆弱性対策情報」（一次・公的機関）
- FIRST「Common Vulnerability Scoring System（CVSS）」（一次・仕様策定団体）
- IPA「情報セキュリティ10大脅威」（一次・公的機関）
※CVSSの版数や区分の考え方、各脆弱性の評価は更新されることがあります。個別の脆弱性への対応可否は、製品ベンダーの公式アドバイザリと自社の構成をもって判断してください。本記事は判断の順序を整理したもので、個別案件のリスク評価を代替するものではありません。
