📅 2026年8月1日 ⏱️ 14分で読めます

security.txtの設置・更新方法｜脆弱性報告窓口を見つけてもらう運用

Q: /security.txt と /.well-known/security.txt のどちらへ置きますか？

RFC 9116に沿う正規の配置先は /.well-known/security.txt です。トップレベルの /security.txt は互換目的で正規URLへリダイレクトできます。両方へ別内容を置かず、正本を一つにしてください。

Q: Contactに問い合わせフォームを指定できますか？

できます。HTTPSの報告フォームURLを Contact へ記載できます。フォームが機微な情報を安全に受け取れるか、添付・通知・アクセス権・保存期間を確認し、障害時の代替連絡先も用意してください。

執筆ファネルAi編集部編集ファネルAi編集部監修ファネルAi監修チーム最終更新2026年8月1日

Webサイトの脆弱性を見つけた人が善意で連絡しようとしても、問い合わせフォームしか見つからない、担当部署が分からない、機微な情報を安全に送れない、といった状態では報告が届くまでに時間がかかります。一般窓口へ届いても、内容の判断ができないまま保留されたり、制作会社・開発会社・情報システム部門の間を転送されたりすると、修正の着手も遅れます。

security.txtは、脆弱性報告に使う連絡先や開示ポリシーを、決められた場所と形式で公開するための仕組みです。ただし、ファイルを設置するだけでは不十分です。報告を受け取る窓口、受付確認を返す担当者、技術的な優先度を判断する担当者、修正と報告者への連絡を管理する責任者まで決めて初めて、見つけてもらった情報をリスク低減へつなげられます。

結論として、security.txtはHTTPS上の/.well-known/security.txtへUTF-8のプレーンテキストとして置き、少なくともContactとExpiresを記載します。実務ではPolicy、Canonical、Preferred-Languages、必要に応じてEncryptionも加えます。公開前にGETで200、Content-Type、本文、リダイレクトを確認し、公開後は窓口の受信監視、受付確認、技術トリアージ、修正、期限前更新を一つの運用として管理してください。

本記事のポイント

security.txtは脆弱性報告の連絡先を見つけやすくする案内であり、脆弱性開示ポリシーやテスト許可そのものではない。
RFC 9116ではHTTPS上の/.well-known/security.txtへ置き、ContactとExpiresを必ず記載し、対象ホストごとに公開する。
公開後は窓口監視、受付確認、技術担当への引き継ぎ、優先度判定、期限前更新までを担当者と証跡付きで回す。

security.txtは連絡先の発見を助ける案内ファイル

security.txtは、セキュリティ研究者や利用者が脆弱性を報告するときに、正しい窓口と方針を見つけやすくする機械可読なテキストファイルです。RFC 9116は、報告経路が見つからないために脆弱性が未報告になる問題を減らす目的で、配置場所、フィールド、形式、スコープを定めています。

ここで重要なのは、security.txtが脆弱性対応プロセスそのものではない点です。ファイルは「どこへ、どの方法で報告するか」を案内します。どのシステムを対象にするか、どのような検証行為を認めるか、報告者とどう連絡するか、いつまでに受付確認するかは、別の脆弱性開示ポリシーと社内手順で定めます。

要素	担う役割	単独ではできないこと	運用上の責任者
security.txt	報告窓口、ポリシー、言語、期限を発見可能にする	検証行為の許可、報告の真偽判定、修正	Web・ドメイン管理者
脆弱性開示ポリシー	対象範囲、連絡方法、期待される行為、対応方針を説明する	受信監視、技術トリアージ、修正管理	セキュリティ・法務・サービス責任者
報告受付	安全に情報を受け取り、受付確認と追加質問を行う	影響範囲の確定、改修優先度の決定	一次窓口担当者
社内対応フロー	検証、優先度判定、修正、報告者との調整、記録を進める	外部から窓口を見つけてもらうこと	技術責任者・サービス責任者

RFC 9116は、security.txtがあることをセキュリティテストの許可と解釈してはならないと明記しています。許可する行為や禁止する行為を示したい場合は、Policyからリンクする公開ポリシーに書きます。発見用ファイルと許可条件を混同しないことが、報告者と運営者の双方にとって重要です。

RFC 9116に沿う配置場所・形式・フィールド

Webサービスでは、対象ホストのhttps://example.com/.well-known/security.txtに置きます。トップレベルの/security.txtは旧来の互換用途として/.well-known/security.txtへリダイレクトできますが、両方にファイルがある場合は/.well-known/側が優先されます。HTTPではなくHTTPSで取得でき、Content-Type: text/plain; charset=utf-8として返るようにします。

ファイルの適用範囲は、取得に使ったドメインまたはIPアドレスです。example.comのファイルがapp.example.comやshop.example.comへ自動的に適用されるわけではありません。サブドメインごとに運営者や窓口が異なる場合は、対象ホストごとに公開し、ドメイン台帳と結び付けます。ドメインの所有者、更新期限、復旧経路まで管理する方法は、企業ドメインの更新期限を見逃さない管理方法と共通します。

フィールド	RFC上の扱い	記載内容	公開前の確認
`Contact`	必須、複数可	`mailto:`、`tel:`、HTTPSの報告フォームなど	上から優先順に並べ、実際に受信・返信できるか
`Expires`	必須、1件のみ	RFC 3339形式の有効期限	1年未満を目安にし、期限前の更新予定があるか
`Policy`	任意	脆弱性開示ポリシーのHTTPS URL	対象範囲、報告内容、連絡方針、許可条件が読めるか
`Canonical`	任意	このファイル自身の正規HTTPS URL	実際に取得したURLと一致しているか
`Preferred-Languages`	任意、1件のみ	`ja, en`のような言語タグ	列挙した言語で実際に対応できるか
`Encryption`	任意、複数可	公開鍵そのものではなく、鍵を取得できるHTTPS URL	鍵が失効しておらず、受信担当者が復号できるか
`Acknowledgments`	任意、複数可	協力した報告者を紹介するページ	本人の希望と公開範囲を確認しているか

最小構成でもContactとExpiresは必要です。実務では、報告者が対象範囲と連絡後の流れを判断できるよう、Policyを併記する方が運用しやすくなります。次は記載例です。ドメイン、窓口、期限、公開鍵、ポリシーURLは自社の実体に置き換えてください。

Contact: https://example.com/security-report
        Contact: mailto:security@example.com
        Expires: 2027-01-31T00:00:00Z
        Encryption: https://example.com/security/pgp-key.txt
        Preferred-Languages: ja, en
        Canonical: https://example.com/.well-known/security.txt
        Policy: https://example.com/security-policy

Contactを複数書く場合は、推奨する連絡方法を先に置きます。Webフォームを第一候補にするなら、添付ファイル、連絡先、対象URL、再現手順、影響、公開予定など、初動に必要な項目を安全に受け取れるか確認します。メールを使う場合は、個人のアドレスではなく役割ベースの窓口にし、担当者の異動や退職で受信が止まらないようにします。

設置から初動までを6段階でつなぐ

設置作業は、テキストファイルをサーバーへ置くところから始めるのではなく、報告を受けた後の担当と経路を決めるところから始めます。次の6段階を順に進めると、公開だけが先行して報告が放置される状態を避けやすくなります。

公開サイトのsecurity.txtから安全な報告窓口、受付確認、技術トリアージ、修正、定期更新へつなぐ運用フロー図 — security.txtを公開するだけで終えず、報告窓口の監視、受付確認、技術担当への引き継ぎ、修正、期限前更新までを一つの循環として管理します。

1. 対象ホストと責任者を棚卸しする

コーポレートサイト、サービス、会員画面、API、採用サイト、キャンペーンサイトなど、インターネットから到達できるホストを列挙します。各ホストについて、Web運営者、インフラ管理者、開発責任者、委託先、緊急連絡先を記録し、誰がsecurity.txtを更新できるかも決めます。外部サービスや埋め込みが多いサイトでは、企業サイトの外部スクリプト棚卸しも併用すると、報告内容をどの提供元へ引き継ぐか判断しやすくなります。

2. 安全に受け取れる窓口を用意する

専用メール、セキュアなWebフォーム、暗号化用の公開鍵などを用意します。一般の問い合わせ窓口を流用する場合も、脆弱性報告を識別して所管担当へ転送する条件、営業時間外の通知、迷惑メール判定、添付ファイルの扱いを決めます。フォームは定期的なテスト送信と通知確認を行い、問い合わせフォームの通知漏れを防ぐ監視設計と同じく、代替連絡先を持たせます。

3. 公開ポリシーで対象範囲と期待値を示す

ポリシーには、対象と対象外のシステム、報告に含めてほしい情報、安全な連絡方法、報告後の連絡方針、禁止する行為、個人情報や機密情報の扱いを記載します。許可条件や法的な扱いを定める場合は、セキュリティ、法務、サービス責任者で確認します。security.txtの存在だけを検証許可と受け取られないようにします。

4. ファイルを作成し、対象ホストへ公開する

ContactとExpiresを必須として、運用できるフィールドだけを書きます。使えない暗号化鍵、応答しない電話番号、未完成のポリシーURLを先に載せると、報告者を迷わせます。GitやCMSなど正本を一つに定め、変更者、承認者、公開日、次回更新日を記録します。

5. 外部からGETし、表示ではなく応答を検証する

ブラウザで見えるだけで完了にせず、外部ネットワークからGETしてステータス、ヘッダー、本文を確認します。次のように取得し、200、HTTPS、text/plain、UTF-8、正しいCanonical、将来のExpiresを確認します。CDN、WAF、認証、Bot対策、キャッシュが外部取得を妨げていないかも見ます。

curl -i https://example.com/.well-known/security.txt

6. 期限前更新と受信テストを繰り返す

Expiresの30日から60日前など、自社で更新開始日を決めて通知します。更新時にはファイルの日付だけでなく、各Contactへのテスト、ポリシーURL、公開鍵、担当者、サブドメインの増減を確認します。サイトの変更管理は、コンテンツガバナンスの責任者・レビュー期限・廃止ルールと結び付けると、担当者交代後も続けやすくなります。

security.txtは設置より「届く・返せる・更新できる」運用が重要

脆弱性報告が届いたら、すぐに攻撃やインシデントと決め付ける必要はありません。一方で、一般問い合わせとして後回しにもできません。NCSCのVulnerability Disclosure Toolkitは、報告を無視せず迅速に返答し、影響を受ける製品やサービスの責任者へ渡し、第三者が管理する場合はその事業者と協議する流れを示しています。受信したURLや添付ファイルはフィッシングの可能性も考え、安全な環境で確認します。

段階	担当	最低限残す情報	判断
受信・受付確認	一次窓口	受付時刻、報告者の連絡先、対象、本文、添付の保管先	受信したことを返し、追加情報の連絡方法を示す
安全確認	セキュリティ担当	リンク・添付の検査、個人情報・認証情報の有無	安全な閲覧環境と共有範囲を決める
技術トリアージ	開発・インフラ責任者	再現条件、影響範囲、悪用可能性、対象環境、既知事象との重複	有効、要追加情報、重複、対象外を分類する
優先度・対応	サービス責任者	影響、暫定対策、修正担当、目標日、利用者への影響	緊急緩和、通常修正、監視継続を選ぶ
連絡・終結	窓口と技術担当	報告者への更新、修正確認、公開調整、謝辞の希望	修正完了と残存リスクを確認して閉じる

初回返信や技術確認の目標時間は、体制とサービスの重要度に合わせて決めます。重要なのは、すべての報告を同じ時間で解決すると約束することではなく、受付確認を返す時間、技術担当へ渡す条件、緊急連絡へ切り替える基準を明文化することです。窓口が一人の受信箱だけに依存すると、休暇や異動で止まるため、共有キュー、当番、エスカレーション先を用意します。

報告内容を検証する際は、公開サイトへ無断で再試行せず、許可されたテスト環境やログで再現します。外部通信やブラウザ上の挙動を調べる場合は、CSP Report-Onlyのように、まず観測してから制限や変更を進める方法が有効です。

よくある失敗と公開後の点検項目

最も危険なのは、形式上は公開されているのに、報告が届かない状態です。RFC 9116は、古い情報を残すくらいならファイルがない方がよい場合もあると注意しています。次の症状がないか、公開直後と定期レビューで確認します。

症状	主な原因	直し方
URLが404または認証画面になる	配置先の誤り、静的配信対象外、WAF・認証の適用	`/.well-known/security.txt`を公開対象にし、外部GETで再確認する
HTMLとして返る	SPAのフォールバック、404ページ置換、Content-Type設定漏れ	プレーンテキストを直接返し、`text/plain; charset=utf-8`を確認する
連絡先へ届かない	個人メールの退職、迷惑メール、フォーム通知障害、暗号鍵の失効	役割ベース窓口、共有キュー、定期受信テスト、代替連絡先を用意する
Expiresが過去または遠すぎる	更新担当と通知がない、期限だけ自動延長している	1年未満を目安にし、期限前に連絡先とポリシーを実査して更新する
サブドメインで見つからない	親ドメインのファイルが自動適用されると誤解している	ホスト台帳から対象を洗い出し、各ホストへ配置する
テスト許可と誤解される	公開ポリシーがない、対象・禁止事項が曖昧	`Policy`から対象範囲と条件を示し、security.txt自体は許可ではないと分ける
更新したのに旧内容が返る	CDNやブラウザの長期キャッシュ、複数の正本	キャッシュ制御と無効化を確認し、正本と公開手順を一つにする

点検日は、Expiresだけでなく、人・サービス・ドメインの変更に連動させます。新しいサブドメインを公開したとき、制作会社や運用ベンダーが変わったとき、報告フォームを差し替えたとき、担当者が異動したとき、公開鍵を更新したときは、次回定期日を待たずに確認します。監視では、URLの200だけでなく、本文のContactとExpiresが期待値どおりかまで検査します。

よくある質問

security.txtを置けばサイトの脆弱性が減りますか？

ファイル自体が脆弱性を修正するわけではありません。報告者が正しい窓口を見つけやすくなり、報告を社内の検証・修正へ早く渡せる可能性を高めます。効果を出すには、受信監視、受付確認、技術トリアージ、修正管理まで必要です。

security.txtの設置は法律上の義務ですか？

RFC 9116はInformationalとして公開された技術仕様であり、それ自体がすべての企業へ法的義務を課すものではありません。業界、国・地域、契約、調達条件、製品区分による要求は別に確認してください。義務の有無にかかわらず、公開サービスの報告窓口を明確にする実務的な手段として利用できます。

`/security.txt`と`/.well-known/security.txt`のどちらへ置きますか？

RFC 9116に沿う正規の配置先は/.well-known/security.txtです。トップレベルの/security.txtは互換目的で正規URLへリダイレクトできます。両方へ別内容を置かず、正本を一つにしてください。

Contactに問い合わせフォームを指定できますか？

できます。HTTPSの報告フォームURLをContactへ記載できます。フォームが機微な情報を安全に受け取れるか、添付・通知・アクセス権・保存期間を確認し、障害時の代替連絡先も用意してください。

サブドメインごとにsecurity.txtが必要ですか？

RFC 9116では、ファイルの適用範囲は取得したドメインまたはIPアドレスに限られ、親・子のホストへ自動拡張されません。公開サービスがある各ホストを棚卸しし、必要なホストごとに正規の場所へ配置します。

仕様と運用を確認できる公式資料

RFC Editor：RFC 9116では、配置場所、形式、フィールド、スコープ、期限、セキュリティ上の注意点を確認できます。
英国NCSC：Vulnerability Disclosure Toolkitでは、連絡手段、開示ポリシー、security.txt、受信後の初動を一体で設計する考え方を確認できます。
CISA：Cybersecurity Performance Goals Checklistでは、公開された報告手段、適時の受付・対応、RFC 9116に沿うsecurity.txtを運用項目として確認できます。

メディア一覧へ戻る