プロンプト
自社のSaaSで、顧客に影響を与えた可能性のある修正済みの脆弱性が発見されました。プロダクトチームは、ステータスページやインシデントレビューでの言及にとどめるのではなく、単独のセキュリティアドバイザリを公開するかどうかを決定しなければなりません。意思決定フレームワーク、コンテンツ計画、顧客のアクション、および成功指標を提示してください。
シナリオと制約事項
この脆弱性は一部のバージョンに影響し、修正パッチは利用可能ですが、詳細情報は攻撃者を利する可能性があります。顧客は複数リージョンにまたがっており、コンプライアンス記録やアップグレード期間（メンテナンスウィンドウ）を必要とする顧客もいます。アドバイザリは検証可能かつ購読可能である必要があり、サポート、エンジニアリング、法務の足並みが揃っていなければなりません。
この設問で評価されるポイント
セキュリティアドバイザリ、サービスインシデントレビュー、マーケティングアップデートにおけるそれぞれのユーザーの目的（user jobs）の違いを理解しているか。アドバイザリは顧客が影響範囲と修復方法を評価するのを支援し、インシデントレビューはサービスへの影響と再発防止策を説明します。Atlassianはアドバイザリを修正リリースに紐付け、GitHubは影響を受けるバージョンや脆弱性の詳細にアドバイザリを使用し、CISAは実用的な情報開示ハンドリングの重要性を強調しています。
模範的なアプローチ
悪用可能性、影響を受ける顧客、必要な顧客のアクション、および現在の緩和策を分類します。公開する場合は、識別子、影響を受けるバージョンと修正済みバージョン、タイムライン、検出および緩和手順、サポート窓口、更新履歴を含めます。修正および顧客への事前通知ゲートを通過するまでは、悪用の詳細情報は非公開とします。記録が矛盾しないよう、可用性、検出、対応、防止を扱うインシデントレビューとは明確に切り離します。
重要な詳細
セキュリティ、プロダクト、エンジニアリング、サポート、法務にわたる公開責任マトリクスを作成します。RSSやメール配信による購読、機械可読なフィールドを提供し、リスクの高い顧客には個別の事前通知を行います。修正から通知までの時間、顧客の確認状況、パッチ適用率、誤検知率、更新の適時性を測定します。
よくある落とし穴
顧客のアクションを伴わないCVSSスコアのみの公開、未確認の影響を事実として記載すること、透明性を理由にエクスプロイトの詳細を公開すること、インシデントレビューを脆弱性データベースとして扱うこと、サポート終了バージョンやホスト環境ごとの違いを無視すること。
評価基準
優れた回答では、単独のアドバイザリが必要となるタイミングや、個別通知を先行させるべきケースが説明されます。セキュリティリスク、顧客の信頼、運用コストのバランスを取りながら、開示ゲート、テンプレート、購読チャネル、修正メカニズムを定義できているかが評価されます。単に「透明性のためだけに公開する」という理由は不十分です。
フォローアップ質問
顧客から完全なエクスプロイト詳細を求められた場合、どのように対応しますか？
身元、契約状況、および修復状況を確認した上で、制御されたチャネルを通じて必要な情報を提供します。公開ページはエクスプロイトのリスクを高めることなく実行可能な状態を維持し、情報開示の判断を記録します。
公開後に影響を受けるバージョンのリストに誤りがあった場合はどうしますか？
修正時刻と影響を直ちに明記し、バージョン履歴を保持した上で、購読チャネルを通じて修正情報をプッシュ配信します。サポートチームにも同一の信頼できる情報源（source of truth）を共有します。通知のないサイレント修正は顧客の誤解を招く可能性があります。
アドバイザリが顧客のリスク低減につながったことをどのように証明しますか？
影響を受けるバージョンごとに、閲覧数、確認状況、パッチ適用率、サポートチケット数を関連付けて分析します。誤検知、繰り返される質問、攻撃の兆候を監視し、次回の情報開示プロセスの改善に役立てます。