プロンプトと適用範囲
この総合面接の質問では、小さな公開ファイルをセキュリティ運用の完全なワークフローの中に適切に組み込めるかどうかがテストされます。単にフィールドを暗記して暗唱することではなく、報告エントリポイント、認可の境界、対応の責任体制、およびポリシー上の約束事項を連携させることが要点です。
面接官が評価している点
- RFC 9116 の
/.well-known/security.txtの配置場所と必須フィールドを理解しているか。 - 発見、検証、協調的開示（Coordinated Disclosure）、緊急対応の違いを明確に区別できるか。
- 監視されていないメールボックス、秘密鍵、責任者のいない応答時間の約束などを公開することを回避できるか。
- エントリポイントを機能させるためのオンコールの責任体制、チケット管理、重複排除、およびステータス更新を設計できるか。
確認すべき明確化のための質問
まず、どのドメインと製品が対象範囲（スコープ）であるか、複数のチームが資産を所有しているか、サードパーティがホストする資産も受け付けるか、各チャネルのオンコール担当者は誰か、どのようなテストが許可されているか、脆弱性開示ポリシーがすでに存在するかを確認します。また、目的が単なる発見しやすさ（ディスカバラビリティ）だけなのか、報奨金、暗号化された報告、協調的開示日の設定なども含むのかを明確にします。
30秒の回答フレームワーク
各公開資産に対して、HTTPS 経由の /.well-known/security.txt に UTF-8 プレーンテキストファイルを公開します。有効な Contact と将来の日時を示す Expires を維持し、それらのプロセスが実際に存在する場合にのみ Policy、Canonical、Encryption、または Acknowledgments を追加します。このファイルは研究者がエントリポイントを見つけるのを助けるだけにすぎません。バックエンドには依然として認可スコープ、オンコールの責任体制、チケット、重複排除、重大度評価、および安全なステータス通知が必要です。公開前には、HTTPS、有効期限、リンクの権限、および責任者のローテーションを検証します。
ステップバイステップの解決策
1. 資産とエントリポイントの境界を定義する
マーケティング用のトップページだけに1つのファイルを配置するのではなく、対象範囲とする必要があるプライマリドメイン、製品ドメイン、および高リスクな API を一覧化します。Contact は、実際に報告を処理できるメールボックスまたは HTTPS フォームを指す必要があります。監視されていない個人のメールボックスを唯一の連絡手段にしてはなりません。異なるチームが資産を所有している場合は、報告がどのようにルーティングされるかを文書化します。
2. RFC 9116 フィールドを設定し、継続的に検証する
Contact と Expires は必須です。Expires には将来の有効期限を指定する必要があります。Policy は許可されたテストおよび開示ルールへのリンクを設定でき、Canonical は正規（canonical）ファイルを識別でき、Encryption は管理されている公開鍵が存在する場合にのみ記載し、Acknowledgments や Hiring は任意です。HTML レンダリングに依存せず、HTTPS の /.well-known/security.txt で text/plain としてファイルを提供します。
3. ファイルを対応ワークフローに連携させる
報告が届いたら、予測困難なチケット識別子を作成し、受領日時、対象資産、再現手順、および研究者が希望する連絡方法を記録します。オンコール担当者はまず認可スコープを確認し、次に重複排除を行い、影響度を評価して、担当者を割り当てます。高リスクの報告は緊急パスに進み、通常の報告は標準キューを使用し、どちらにも監査証跡を残します。
4. 無理な SLA を作るのではなく、開示ポリシーを作成する
ポリシーには、許可される調査行為、禁止事項、機密資料の安全な送信方法、報奨金（ある場合）、公開開示が許可されるタイミング、および善意のテスト（good-faith testing）の扱いを明記する必要があります。持続可能な受領確認時間と更新頻度のみを明文化してください。RFC のフィールドを、すべての報告が特定の時間内に修正されるという約束として解釈してはなりません。
5. エントリポイントと報告データを保護する
公開ファイルには、秘密鍵、内部ホスト名、個人の電話番号、または未公開のインシデント詳細を含めてはなりません。添付ファイルの形式とサイズを制限し、メールやチケットシステムへのアクセスを制限し、未加工の報告に含まれるスクリプトやリンクは信頼できない入力として扱います。セキュリティチームはより詳細な内部コンテキストを保持できますが、報告者への返信には承認された事実のみを開示します。
6. オブザーバビリティによってエントリポイントが機能していることを証明する
ファイルの 200 応答、HTTPS 証明書、Expires までの残り時間、オンコールのローテーション、およびフォームからチケットへの変換を監視します。無害なテスト報告を使用して、アラート、重複排除、およびエスカレーションを検証します。訓練のために本物の脆弱性を使用してはなりません。CDN、リダイレクト、およびマルチリージョンデプロイメントが、古いまたは期限切れのコピーを提供していないことを確認します。
高品質な回答例
まず対象範囲とする公開ドメインをリストアップし、それぞれに対して HTTPS の /.well-known/security.txt に UTF-8 プレーンテキストファイルを公開します。Contact は担当者が配置されたメールボックスまたはフォームを指し、Expires は将来の日時に設定して有効期限アラートでカバーします。Policy、Canonical、または Encryption は、それらのプロセスや鍵が維持管理されている場合にのみ追加します。ファイルでは修正期限を約束しません。ポリシーにおいて認可されたスコープ、禁止事項、機密資料の送信、報奨金、および協調的開示を規定します。報告はアクセス制限されたチケットシステムに入り、スコープ確認、重複排除、重大度評価、および担当者割り当てが行われ、高リスク案件には緊急パスが用意されます。公開前に HTTPS、キャッシュ、権限、オンコールの体制、更新プロセスを検証し、その後は到達性、チケット変換、対応状況を監視します。ファイルはチャネルを発見可能にし、ワークフローと責任体制がセキュリティ機能を提供します。
よくある間違い
- オンコールの責任者、チケットキュー、またはエスカレーションパスを用意せずにファイルを作成すること。
Expiresを省略し、研究者に機能しない可能性のある連絡先情報を残してしまうこと。- 秘密鍵、内部アドレス、または個人の電話番号を公開すること。
- チームが維持できない修正 SLA、報奨金額、または開示日を約束すること。
- 安定した HTTPS エントリポイントを HTTP、ログインリダイレクト、または CDN 上の古いコピーに置き換えてしまうこと。
- 認可と影響が確認される前に再現手順の詳細を公開してしまうこと。
フォローアップの質問と回答
security.txt は脆弱性開示ポリシーの代わりになりますか？
いいえ。これは研究者が Contact や Policy のリンクを見つけるのに役立つものです。認可スコープ、善意のテスト、報奨金、開示の調整、および緊急時のルールは、依然としてポリシーに記載されるべき事項です。
なぜ Expires が必要なのですか？
連絡先やプロセスは変化します。Expires を設定することで、自動チェックによって古くなっている可能性があるファイルを特定し、古いメールボックスが無期限に有効であるかのように見えるのを防ぎ、チームが確実に更新できるようにします。
グループ内に多数の製品ドメインがある場合はどうすればよいですか？
個別に所有されているドメインごとに対応するファイルを公開し、Canonical またはポリシーリンクを使用して正式なソース（authoritative source）を説明します。各エントリポイントは報告を適切にルーティングできるチームにつながっている必要があり、監視されていないアドレスを単にコピーするだけでは不十分です。
研究者からゼロデイの疑いがある報告を受けた後の最初のステップは何ですか？
報告へのアクセスを制限し、送信元と資産のスコープを確認し、日時と証拠を記録して、緊急の影響度評価のためにセキュリティ責任者に通知します。未検証の詳細を公開チャネルに転送したり、報告をより完全なものにするためだけに研究者にテストの拡大を求めたりしてはなりません。