security.txtの設定：必須項目と確認チェックリスト

迷わず見つけられる報告先

誰かが貴社のウェブサイトで問題の可能性に気付き、知らせようとしています。営業、サポート、複数の委託先をたどる必要があれば、避けられるはずの遅れが生じます。報告経路が明確なら、報告者は宛先を見つけられ、企業は判断に使える情報を受け取れます。

RFC 9116 は security.txt を定義しています。ウェブサービスでは /.well-known/security.txt に配置し、HTTPS で提供します。Contact と Expires は必須項目です。

導入時には、公開ドメイン、運営担当、各ドメインの報告先を簡単な一覧にします。連絡先を公開する前に、実際に対応する担当者と運用を確認してください。 [1]

受信箱に責任者を置く

責任者と代行者を決めます。新着の確認、技術的な判断、不在時の引き継ぎを誰が行うかを合意します。複数の委託先が関わる場合は、それぞれが担当するサービスも明確にします。

明示的に合意したうえで、識別しやすい件名の無害な到達テストを行います。送信の成功だけでなく、指定の受信箱に届くか、対応の流れに入るか、担当者が返信できるかを確認します。ファイルが公開されているだけでは、これらは分かりません。

共有チケットや社内の受付番号から始められます。受信時刻、対象サービス、担当者、次の対応を記録します。機微な情報を必要以上に広い配布先へ転送しないようにします。

報告の流れを可視化する

図では四つの役割を分けています。公開ファイルが連絡先を示し、窓口が報告を受け付けます。担当者は自社システムとの関係を確認し、返信によってやり取りを継続します。

小規模なチームでも同じ考え方で運用できます。現在の担当者、未解決の問い、次の対応を確認する時点を明確にして引き継ぎます。外部事業者が運営するサービスなら、その事業者への引き継ぎも含めます。

連絡先と調査のルールを併記する

連絡先の公開だけで、セキュリティ診断を依頼したことにはなりません。観察した事実の報告と、追加のテストを行う許可は分けて考えます。

NCSC は、連絡経路、必要な情報、想定される返信、許容される調査範囲を示す、分かりやすい開示方針を推奨しています。

最初の連絡には、対象のアドレス、簡潔な説明、観察した時刻を記載することを勧めます。この段階でパスワードや大量の個人データは必要ありません。追加の証拠が必要なら、適切な送付方法を相談します。返信期限は、チームが確実に守れるものだけを公表します。 [2]

変更のたびに見直す

セキュリティ窓口を業務上の連絡先として管理します。ドメイン移行、IT 委託先の変更、担当者の退職時のチェックリストに含めます。公開情報の有効期限より前に確認日を設定します。

最初の定期確認は簡潔で構いません。公開ファイルを取得し、記載内容を社内の担当分担と照合して、合意した報告経路を確認します。結果と日付を記録することで、一度置いたままのファイルを、有用な報告を受け付ける継続的な窓口にできます。

項目とHTTPレスポンスを確認する

Webサービスでは、/.well-known/security.txtをHTTPSで公開し、UTF-8のテキストとtext/plainのメディアタイプを使用します。ステータス200を返すHTMLエラーページは、有効なsecurity.txtではありません。本文とレスポンスヘッダーを合わせて確認します。

適用範囲は限定されます。example.comのファイルが、そのサブドメインすべてに自動適用されるわけではありません。対象ホストを個別に把握してください。以下は一部の項目であり、RFC 9116への完全な適合性確認ではありません。 [1]

表は左右にスクロールできます。

確認結果と担当者を記録する

記入式チェックリストは、公開ファイルと社内の受付手順を結び付けます。ドメインごとにコピーを作り、実測結果と次回確認日を記録してください。自動スキャナーではなく、これだけで設定の安全性を認証するものでもありません。

security.txtチェックリストをダウンロード