脆弱性・脅威・リスク・インシデントの違い｜Web担当者のための4つの使い分け

この4語は、指している「段階」が違います。脆弱性は自社の弱点、脅威は外から危害を与えうる原因、リスクはその組み合わせで決まる損害の見込み、インシデントは実際に起きた（または起きた疑いのある）事象です。対策では脆弱性をふさぎ、脅威を前提にリスクで優先順位を付け、インシデントになると期限付きの報告が始まります。この対応関係を押さえると、ニュースも社内報告も読み違えにくくなります。

4語の関係を自社サイトに当てはめる

NISTの用語集では、脆弱性は「脅威源によって悪用または誘発されうる、情報システムや手順・内部統制・実装上の弱点」と定義され、インシデントは機密性・完全性・可用性が実際にまたは切迫して脅かされる事象、あるいはポリシー違反と定義されています。つまり脆弱性は「状態」、インシデントは「出来事」です。

自社サイトに置き換えると、次のようにつながります。

• 脆弱性：問い合わせフォームを動かすCMSのプラグインが古いまま／管理画面がインターネットから誰でも開ける
• 脅威：改ざん可能なサイトを自動で探し回る攻撃ボット、委託先経由で侵入する攻撃者
• リスク：フォームが改ざんされ、入力された氏名・連絡先が第三者に送信される可能性と、その場合の影響の大きさ
• インシデント：実際にページが改ざんされていた、あるいは改ざんの痕跡が見つかった

「脆弱性が発生した」「リスクが起きた」という表現が混乱のもとです。脆弱性は公表される・存在するもの、リスクは高い・低いと評価するもの、発生するのはインシデントだけ、と整理すると使い分けが安定します。

脆弱性：4つのうち唯一、自社で直せる要素

Webサイト運営で実際に問題になる脆弱性は、大きく3種類です。1つ目はソフトウェアの既知の欠陥（CMS本体・プラグイン・テーマ・サーバーのミドルウェア）。2つ目は設定ミス（公開範囲の誤り、ディレクトリの露出、テスト環境の放置）。3つ目は認証・権限の弱さ（管理画面のアクセス制限なし、多要素認証なし、退職者アカウントの残存）です。

1つ目は番号で追跡できます。JPCERT/CCのWeekly Report 2026年10月15日号では、WordPress、Movable Type、Drupalのモジュールなど、サイト運営で使われる製品の脆弱性が並んで挙げられています。自社で使っている製品名を、この種の一覧と照合できる状態にしておくことが脆弱性管理の出発点です。

注意したいのは、深刻度スコア（CVSS）は脆弱性そのものの評価であって、自社のリスクではない点です。IPAも、CVSS基本値だけでは優先順位が付けにくいとして、悪用状況としての「脅威」、深刻度としての「脆弱性」、環境情報としての「資産」を組み合わせて評価する考え方を示しています。

脅威：なくせない前提として読むもの

脅威は攻撃者や攻撃手口そのものなので、自社の努力では消えません。できるのは、何が狙われているかを把握して備えを調整することです。

IPAが2026年1月に公表した「情報セキュリティ10大脅威 2026」の組織向けでは、1位がランサム攻撃による被害、2位がサプライチェーンや委託先を狙った攻撃、3位にAIの利用をめぐるサイバーリスクが初選出、4位がシステムの脆弱性を悪用した攻撃でした。Web担当者の立場で読み替えるなら、2位は制作会社・保守委託先・外部ツールの経路、4位は公開サーバーやCMSの更新遅れが該当します。

JPCERT/CCも2026年10月に「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」を更新しています。脅威の情報は「自社の資産のうち、どれが同じ手口の射程に入るか」を確認する材料として使うのが実務的です。

リスク：優先順位を決めるための単位

デジタル庁のセキュリティリスク分析ガイドラインは、リスクを「目的に対する不確かさの影響」とし、ある事象の結果と起こりやすさの組合せで表現されることが多いと説明しています。脅威と脆弱性が同じでも、守る資産の重要度が違えばリスクの大きさは変わります。

サイト運営でリスクを見積もるときは、次の4点を順に確認すると判断がぶれません。

1. 資産：対象サイトが扱うデータ（問い合わせ内容、会員情報、決済情報）と、停止したときの業務影響
2. 露出：インターネットから到達できるか、認証の有無、管理画面のアクセス制限
3. 影響：漏えい、改ざん、停止のうちどれが起きうるか。顧客通知や公表が必要になる規模か
4. 対応コスト：更新の作業量、停止調整、代替策（WAF、アクセス制限）の有無

同じ深刻度の脆弱性でも、個人情報を受け取る本番フォームと、社外から到達できない検証環境では優先度が変わります。すぐに直せない場合は「対応しない」ではなく、受容したリスクとして期限と暫定策を記録するのが正しい扱いです。

インシデント：「おそれ」の段階で時計が動き出す

インシデント対応で重要なのは、確定を待たないことです。個人情報保護委員会は、報告が必要な事態として「漏えい等が発生し、又は発生したおそれがある」場合を挙げており、例として「ウェブサイトが改ざんされ、ユーザーが入力した個人情報が第三者に送信された場合」「システムの設定ミス等によりインターネット上で個人データの閲覧が可能な状態となり、本人の数が1,000人を超える場合」を示しています。

報告の期限は2段階です。速報は発覚日から3〜5日以内、確報は発覚日から30日以内（不正な目的で行われたおそれがある場合は60日以内）。起算点は発生日ではなく発覚日で、法人の場合はいずれかの部署が事態を知った時点が基準とされています。現場が気づいてから担当者に伝わるまでに数日かかると、速報の目安はその時点でほぼ消えます。

また2026年10月1日以降は、ランサムウェア事案に加えて「その他サイバー攻撃等事案」についても、関係省庁申合せに基づく共通様式で報告できるようになっています。技術的な調整や相談が必要な場合は、JPCERT/CCのインシデント対応依頼の窓口も使えます。

どの段階でどの語を使うか

用語は、業務のフェーズとほぼ一対一で対応します。

• 平常時の棚卸し・診断・パッチ適用：脆弱性。「どこに弱点があるか」を列挙する段階
• 注意喚起やニュースの読解：脅威と脆弱性を分けて読む。手口（脅威）が自社のどの弱点（脆弱性）に刺さるかを確認する
• 年間計画・経営への説明：リスク。脅威と脆弱性は前提として、資産と影響で優先順位を示す
• 発生時・報告時：インシデント。期限と報告先が発生するのはこの段階だけ

社内報告で「脆弱性が出ました」とだけ書くと、受け手が「侵害が起きたのか、まだ弱点の話なのか」を判断できません。報告の1行目に「弱点の発見か、侵害の疑いか」を明示するだけで、発覚日の起算やエスカレーションの要否がはっきりします。

今週できる4つの準備

1. 公開資産の一覧をつくる：ドメイン、サーバー、CMSとプラグインのバージョン、フォームの送信先、関与する委託先
2. 情報源を固定する：JVNやJPCERT/CCの注意喚起を担当者が定期的に見る運用にし、該当製品を照合する
3. 優先度の基準を決める：CVSSに加え、露出の有無と扱うデータで判断する社内ルールを1枚にまとめる
4. 発覚から1時間の動きを決める：誰に連絡し、誰がログを保全し、誰が個人情報の有無を確認するかを明記する

4つの用語を区別する実益は、議論を正しい場所に置けることにあります。弱点の話なら修正計画、手口の話なら備えの見直し、優先順位の話なら資産と影響の評価、起きた話なら期限付きの初動と報告です。まずは自社サイトの資産一覧と、発覚時の連絡経路を書き出すところから始めてください。

出典

• NIST CSRC 用語集: vulnerability（脆弱性）の定義
• NIST CSRC 用語集: incident（インシデント）の定義
• 個人情報保護委員会: 漏えい等の対応とお役立ち資料
• 個人情報保護委員会: 個人情報の保護に関する法律についてのガイドライン（通則編）
• IPA: 情報セキュリティ10大脅威 2026
• IPA: 脆弱性対応におけるリスク評価手法のまとめ
• デジタル庁: 政府情報システムにおけるセキュリティリスク分析ガイドライン（DS-201）
• JPCERT/CC: Weekly Report 2026-10-15号
• JPCERT/CC: 直近で相次いでいる国内組織における不正アクセスに関する注意喚起
• JPCERT/CC: インシデント対応依頼