脆弱性対応の流れとは？受付からパッチ公開まで【SG試験】

まず結論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これは危険です。
対策が用意される前に詳細を公開すると、攻撃者に悪用される可能性があります。

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

開発部門は修正を担当しますが、対応全体は開発だけでは完結しません。

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

パッチを公開しても、利用者が適用しなければリスクは残ります。

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

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

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