---
title: "脆弱性対応の流れとは？受付からパッチ公開まで【SG試験】"
description: "脆弱性対応の流れは、脆弱性情報を受け付け、影響を確認し、修正・回避策・公表まで進める手順です。SG試験で迷いやすい役割分担と判断基準を整理します。 試験対策として重要語の定義・具体例・よくある誤解をまとめ、短時間で復習できるように整理しています。"
last_modified_at: "2026-06-10"
canonical_url: "https://stemtazoo.github.io/sg/vulnerability-response-flow/"
section: "sg"
---

## まず結論
- **脆弱性対応の流れとは、脆弱性情報を受け付け、影響を確認し、修正や回避策を準備し、必要に応じて公表するまでの一連の対応**です。
- SG試験では、「発見したらすぐ公開する」のではなく、悪用を防ぐために、受付・確認・調整・修正・公表の順に進める考え方が問われます。

脆弱性情報は、扱い方を間違えると攻撃に悪用されるおそれがあります。  
そのため、対応では **早く知らせること** と **むやみに公開しないこと** のバランスが重要です。

選択肢では、**誰が受け付けるのか、誰が修正するのか、いつ公表するのか**を切り分けます。

## 直感的な説明
脆弱性対応は、製品の欠陥が見つかったときのリコール対応に似ています。

例えば、あるソフトウェアに危険な欠陥が見つかったとします。  
このとき、いきなりインターネット上に詳細な攻撃方法を公開すると、まだ修正できていない利用者が攻撃されるかもしれません。

一方で、開発者が何も対応しなければ、利用者は危険に気づけません。

そこで、次のような流れで対応します。

- 情報を受け付ける
- 本当に脆弱性か確認する
- どの製品やバージョンに影響するか調べる
- 修正プログラムや回避策を準備する
- 関係者と公表時期を調整する
- 利用者に対策情報を知らせる

つまり、脆弱性対応は「見つけたらすぐ公開」ではなく、**利用者を守るために、関係者が準備してから公表する流れ**と考えると理解しやすいです。

## 定義・仕組み
脆弱性対応では、発見者、受付機関、調整機関、製品開発者、利用者などが関わります。  
日本では、脆弱性関連情報の届出受付や取扱いについて、IPAやJPCERT/CCが重要な役割を担います。

公式情報は、IPAの [脆弱性関連情報の届出受付](https://www.ipa.go.jp/security/todokede/vuln/uketsuke.html) や、JPCERT/CCの [脆弱性情報ハンドリングとは？](https://www.jpcert.or.jp/vh/) で確認できます。

代表的な流れは、次のように整理できます。

| 手順 | 内容 | 主な関係者 |
|---|---|---|
| 1. 発見・届出 | 脆弱性を見つけた人が情報を届け出る | 発見者、IPAなど |
| 2. 受付・確認 | 届出内容を確認し、脆弱性情報として扱うか整理する | IPAなど |
| 3. 連絡・調整 | 影響を受ける製品開発者へ連絡し、対応を調整する | JPCERT/CC、製品開発者 |
| 4. 影響調査 | 対象製品、対象バージョン、悪用可能性を確認する | 製品開発者、PSIRT |
| 5. 対策準備 | パッチ、設定変更、回避策、注意喚起文を準備する | 製品開発者、PSIRT |
| 6. 公表 | 対策情報を利用者に知らせる | 製品開発者、関係機関 |
| 7. 適用・運用 | 利用者がパッチ適用や回避策を実施する | 利用者、運用担当者 |

この流れで大切なのは、**公表前の情報を慎重に扱うこと**です。  
脆弱性の詳細が対策前に広がると、攻撃者に利用される可能性があります。

そのため、脆弱性情報は、関係者の間で必要な範囲に絞って共有し、対策の準備ができた段階で公表するのが基本です。

## どんな場面で使う？
脆弱性対応の流れは、製品やシステムの安全性を保つ場面で使います。

例えば、次のような場面です。

- 自社製品に脆弱性報告が届いた
- 利用中のソフトウェアに重大な脆弱性が公表された
- 外部研究者から製品の問題を指摘された
- パッチ公開前に関係者間で調整が必要になった
- パッチ適用までの間、回避策を利用者に知らせる必要がある

SG試験では、立場ごとの役割を切り分けることが重要です。

| 立場 | 主な役割 |
|---|---|
| 発見者 | 脆弱性を見つけ、適切な窓口へ届け出る |
| IPA | 脆弱性関連情報の届出を受け付ける |
| JPCERT/CC | 製品開発者や関係機関との調整を行う |
| PSIRT | 自社製品の影響確認、修正、注意喚起を進める |
| 利用者 | 公表された対策情報に基づき、パッチ適用や設定変更を行う |

特に、製品開発者側ではPSIRTが中心になります。  
PSIRTは、開発部門、品質保証部門、法務、広報などと連携しながら、対策と公表を進めます。

一方で、利用者側の対応は少し違います。  
利用者は脆弱性を修正する側ではなく、**公開されたパッチを適用し、必要に応じて回避策を実施する側**です。

## よくある誤解・混同
脆弱性対応では、次のような誤解がよくあります。

### 誤解1：脆弱性を見つけたらすぐ公表する
これは危険です。  
対策が用意される前に詳細を公開すると、攻撃者に悪用される可能性があります。

SG試験では、**無制限に公開する選択肢**や、**関係者との調整なしに詳細を公表する選択肢**は注意します。

### 誤解2：脆弱性対応は開発部門だけの仕事
開発部門は修正を担当しますが、対応全体は開発だけでは完結しません。

実際には、PSIRT、品質保証、法務、広報、サポート部門などが連携します。  
対策情報の公表や顧客対応も含まれるため、組織的な対応が必要です。

### 誤解3：パッチ公開で対応は終わり
パッチを公開しても、利用者が適用しなければリスクは残ります。

そのため、運用側では次の対応が必要です。

- 影響を受ける製品を使っているか確認する
- パッチ適用の優先度を決める
- すぐ適用できない場合は回避策を実施する
- 適用後に問題がないか確認する

### 誤解4：脆弱性対応とインシデント対応は同じ
脆弱性対応は、弱点が見つかった段階での対応です。  
インシデント対応は、実際に攻撃や被害が発生した、または発生が疑われる段階での対応です。

- 脆弱性対応：弱点を修正し、悪用を防ぐ
- インシデント対応：発生した被害を封じ込め、調査し、復旧する

SG試験では、「事前に弱点を直す話」なのか、「発生した被害に対応する話」なのかを確認すると選択肢を切りやすくなります。


## SG試験で選択肢を切る判断軸（取扱基準編）

- 「受付機関が発見者の氏名・連絡先をWebサイト運営者へ渡す」と書かれている  
  → **誤り**。発見者を特定し得る情報は、同意なく開示しないのが基本です。

- 「Webサイト運営者は、漏えい等が発生しても公表しない」と書かれている  
  → **誤り**。二次被害防止や類似事案の回避のため、可能な限り事実関係を公表する方向で判断します。

- 「受付機関は、修正通知を受けたら発見者へ速やかに伝える」と書かれている  
  → **適切**。連絡の往復を止めず、対応完了までつなぐ役割が問われます。

- 「届出状況は不安を与えるので公表しない」と書かれている  
  → **不適切**。被害予防に資する範囲で、届出状況等を公表する考え方を押さえます。

迷ったら、**「誰の情報を守る話か（発見者情報）」と「誰を守るために公表する話か（利用者保護）」**を分けて読みます。

## まとめ（試験直前用）
- 先に「事前の脆弱性対応」か「発生後のインシデント対応」かを判定する。
- 脆弱性対応は **受付→確認→調整→影響調査→対策準備→公表→適用** の順で考える。
- 役割は「IPA＝受付」「JPCERT/CC＝調整」「PSIRT＝製品影響確認と対策」で切り分ける。
- 対策前の無秩序な公開は避け、公開タイミングは調整後に判断する。
- 迷ったら「誰の役割か」「いつ公表か」「適用済みか」で選択肢を切る。