最終更新日：2026年6月13日
sg sg-security-management incident_management threat_vulnerability
まず結論
ソフトウエア等脆弱性関連情報取扱基準とは、ソフトウエア製品やWebアプリケーションの脆弱性情報を、発見者・受付機関・調整機関・製品開発者・Webサイト運営者などが安全に取り扱うための基準です。
SG試験では、暗号技術や攻撃手法そのものよりも、脆弱性を見つけた後に、誰が、誰へ、何を、どのように扱うべきかを判断させる問題として出やすいです。
特に、次のような切り分けが重要です。
| 迷いやすい点 | 判断のポイント |
|---|---|
| 発見者がすぐ公表してよいか | 原則として、受付機関へ届け出る。むやみに第三者へ開示しない |
| 受付機関と調整機関の違い | 受付機関は届出を受ける。調整機関は製品開発者との連絡・公表調整を行う |
| Webサイト運営者の役割 | 自分のサイトの脆弱性を確認し、修正や利用者保護などの対応を行う |
| 受付機関は発見者情報を自由に伝えてよいか | 発見者の同意がない場合、氏名・連絡先などを勝手に開示しない |
選択肢では、「勝手に公表する」「発見者情報を無断で渡す」「受付機関と調整機関の役割を逆にする」と書かれていたら注意です。
直感的な説明
脆弱性情報は、言い換えると「まだ直っていない弱点の情報」です。
たとえば、あるWebサイトに「他人の個人情報が見えてしまう不具合」が見つかったとします。この情報をいきなりSNSや掲示板で公開すると、悪意のある人に悪用され、被害が広がるおそれがあります。
一方で、Webサイト運営者に何も伝わらなければ、修正も利用者保護も進みません。
つまり、脆弱性情報は、隠しすぎても危険、広めすぎても危険です。
そこで必要になるのが、脆弱性情報を安全に受け付け、関係者へ伝え、修正や公表につなげるためのルールです。これが、ソフトウエア等脆弱性関連情報取扱基準の考え方です。
英語でいうと、脆弱性情報の取扱いは responsible disclosure や coordinated vulnerability disclosure に近い考え方です。ポイントは「発見した人が勝手に公開する」のではなく、関係者が調整して被害を防ぐことです。
SG試験では、ここを「親切に知らせれば何でもよい」と考えるとひっかかります。重要なのは、被害を防ぐために、適切な相手へ、適切な手順で伝えることです。
定義・仕組み
ソフトウエア等脆弱性関連情報取扱基準は、脆弱性関連情報の取扱いについて、関係者ごとの推奨される行動を定めた基準です。
対象になるのは、大きく分けると次の2つです。
| 対象 | 例 |
|---|---|
| ソフトウエア製品 | OS、アプリケーション、ミドルウェア、組込みソフトなど |
| Webアプリケーション | Webサイト上で動く入力フォーム、会員ページ、予約システムなど |
この基準の中心は、脆弱性情報を「誰かが知って終わり」にせず、受付、連絡、調整、修正、公表につなげることです。
主な関係者は次のとおりです。
| 関係者 | 役割 |
|---|---|
| 発見者 | 脆弱性を発見し、受付機関へ届け出る人 |
| 受付機関 | 脆弱性関連情報の届出を受け付ける機関 |
| 調整機関 | 製品開発者への連絡や、公表時期などの調整を行う機関 |
| 製品開発者 | ソフトウエア製品の脆弱性を確認し、修正や対策情報を準備する者 |
| Webサイト運営者 | 自分のWebサイトの脆弱性を確認し、修正や被害防止策を行う者 |
日本では、IPAが脆弱性関連情報の届出受付を行っており、ソフトウエア製品についてはJPCERT/CCが製品開発者との調整を担います。詳しくは、IPAの脆弱性関連情報の届出受付、経済産業省の国内における脆弱性関連情報を取り扱う全ての皆様へ、およびソフトウエア等脆弱性関連情報取扱基準（PDF）で確認できます。
基本の流れは、次のように整理できます。
- 発見者が脆弱性を見つける
- 発見者が受付機関へ届け出る
- 受付機関が内容を確認する
- ソフトウエア製品の場合は、調整機関が製品開発者との連絡・調整を行う
- 製品開発者やWebサイト運営者が修正・対策を行う
- 必要に応じて、利用者に向けた対策情報などを公表する
ここで大切なのは、公表は目的ではなく、被害を防ぐための手段ということです。
SG試験では「脆弱性情報を公表するかどうか」だけでなく、修正前に広めると悪用されるリスクがあること、修正後や対策準備後に必要な範囲で公表する意味があることを押さえておくと、選択肢を切りやすくなります。
どんな場面で使う？
この基準は、脆弱性を発見した人、脆弱性の届出を受けた組織、Webサイトを運営する組織、ソフトウエア製品を提供する組織などが、脆弱性情報を扱う場面で使います。
たとえば、次のような場面です。
| 場面 | 取るべき考え方 |
|---|---|
| 外部の人が自社Webサイトの脆弱性を発見した | 感情的に拒否せず、内容を確認し、被害防止と修正を進める |
| 自社が利用しているソフトに脆弱性情報が公表された | 修正プログラムや回避策を確認し、適用の要否を判断する |
| 発見者から連絡先情報を受け取った | 同意なく第三者へ開示しない |
| 脆弱性が個人情報漏えいにつながる可能性がある | 修正だけでなく、利用者保護、二次被害防止、公表の要否を検討する |
科目Bのケース問題では、会社のWebサイト、委託先が運用するシステム、外部からの脆弱性連絡などの形で出てくることがあります。
このときの判断基準は、次の3つです。
- 誰の役割かを確認する
- 修正前に広めていないかを確認する
- 被害防止につながる対応かを確認する
選択肢では、「一般利用者に不安を与えないため、公表しない」と書かれることがあります。しかし、脆弱性に起因する個人情報漏えいなどが発生した場合は、二次被害の防止や類似事案の発生回避のため、事実関係等を公表するなど必要な対策が求められます。
つまり、不安を与えないために隠すのではなく、被害を防ぐために必要な情報を適切に扱うと考えるのがポイントです。
よくある誤解・混同
ソフトウエア等脆弱性関連情報取扱基準でよくある誤解は、「脆弱性を見つけたら、すぐ世の中に知らせるのが正しい」と考えてしまうことです。
もちろん、利用者を守るために情報を伝えることは大切です。しかし、修正前の脆弱性情報を広く公開すると、攻撃者に悪用される危険があります。
SG試験では、次のようなひっかけに注意してください。
| ひっかけ | なぜ誤りか |
|---|---|
| 発見者は注意喚起のため、脆弱性の詳細をすぐ公表する | 修正前に悪用される可能性があるため、原則として受付機関へ届け出る |
| 受付機関は、発見者の氏名・連絡先をWebサイト運営者へ通知する | 発見者の同意がない場合、氏名・連絡先などを勝手に開示しない |
| 受付機関は、Webサイト運営者から修正完了の通知を受けたら、その旨を発見者へ速やかに通知する | 修正されたことを発見者へ知らせる流れとして適切 |
| Webサイト運営者は、利用者に不安を与えないため、個人情報漏えいの事実を公表しない | 二次被害防止や類似事案の発生回避の観点から、必要な公表等を検討する |
| 調整機関は、すべてのWebサイト運営者の修正作業を直接代行する | 調整機関は連絡・調整が中心であり、運営者の修正作業そのものを代行する役割ではない |
特に混同しやすいのが、受付機関と調整機関です。
受付機関は「届出を受ける窓口」です。調整機関は「製品開発者との連絡や公表の調整を行う役割」です。
英語で覚えるなら、受付機関は reception point、調整機関は coordination body のイメージです。試験では、名前よりも「何をする役割か」で判断しましょう。
また、Webアプリケーションの脆弱性では、Webサイト運営者が自分のサイトの修正や利用者保護を行います。ソフトウエア製品の脆弱性では、製品開発者が修正プログラムや回避策の準備を行います。
SG試験では、ソフトウエア製品の話なのか、Webアプリケーションの話なのかを読み分けることも大切です。
まとめ（試験直前用）
ソフトウエア等脆弱性関連情報取扱基準は、脆弱性情報を安全に届け出て、修正・調整・公表につなげるための基準です。
発見者は、脆弱性を見つけても、むやみに第三者へ開示せず、受付機関へ届け出ると考えます。
受付機関は届出を受ける役割、調整機関は製品開発者との連絡・公表調整を行う役割です。
Webサイト運営者や製品開発者は、脆弱性を確認し、修正や被害防止策を進めます。
選択肢では、「すぐ公表する」「発見者情報を無断で伝える」「受付機関と調整機関を取り違える」「利用者保護より隠すことを優先する」と書かれていたら注意しましょう。