Security.txt ジェネレーター

security.txt は IETF（インターネット技術タスクフォース）が RFC 9116 で正式に標準化したWebセキュリティのベストプラクティスであり、ウェブサイトがセキュリティ連絡先情報を公開するための統一された標準的な方法を提供することを目的としています。簡単に言えば、これはウェブサイトの固定パスに配置されたテキストファイルで、セキュリティ研究者（ホワイトハッカー）に対して「私のウェブサイトでセキュリティ脆弱性を発見した場合、こちらが私たちへの連絡方法です。こちらが暗号化公開鍵、こちらが開示ポリシーです。報告を歓迎します。」と伝えるものです。

security.txt 標準が登場する前は、ウェブサイトのセキュリティ連絡先情報は統一されていませんでした。セキュリティ連絡先が全く記載されていないサイトもあれば、どこかの隅のページに隠れているサイト、誰も見ていないinfo@メールアドレスだけが記載されているサイト、LinkedInでセキュリティチームを探すのに苦労するサイトもありました。これは深刻な問題を引き起こしました：善意のセキュリティ研究者が脆弱性を発見しても、正しい報告チャネルを見つけられないことが多かったのです。その結果——多くの脆弱性がそのまま放置され、修正されることなく、悪意のあるハッカーに発見・悪用されるまで待つしかありませんでした。security.txt はまさにこの「ラストワンマイル」の問題を解決するために誕生しました。

security.txt のコンセプトは、セキュリティ研究者 EdOverflow と Yakov Shafranovich によって2017年に最初に提案され、業界から幅広い支持を迅速に獲得しました。2022年4月、security.txt は IETF によって正式に RFC 9116 標準として承認され、国際的に認められたWebセキュリティ標準となりました。現在では、Google、GitHub、Meta（Facebook）、LinkedIn、Cloudflareなどの大手テクノロジー企業に加え、英国政府、米国CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）、フランス政府、イタリア政府、オランダ政府、オーストラリアサイバーセキュリティセンターなどの政府機関が公式ウェブサイトに security.txt をデプロイし、他の組織にも採用を公に推奨しています。

security.txt ファイルのコアな設計は非常にシンプルです——一連の「フィールド名: 値」の行で構成される単なるプレーンテキストファイルで、HTTPヘッダーのような形式です。標準では2つの必須フィールドが定義されています：Contact（セキュリティ連絡先、複数指定可）とExpires（ファイル有効期限）。また、複数のオプションフィールドがあります：Encryption（PGP暗号化公開鍵URL）、Acknowledgments（謝辞ページURL）、Policy（脆弱性開示ポリシーURL）、Hiring（セキュリティ採用URL）、Canonical（ファイル正規URL）、Preferred-Languages（対応報告言語）、CSAF（セキュリティアドバイザリフレームワークメタデータURL）。このシンプルなフォーマットにより、人間にも機械にも容易に解析できるようになっています。

なぜ security.txt の導入がこれほど重要なのでしょうか？第一に、脆弱性報告のハードルを下げることです。セキュリティ研究者は連絡先を探すのに多くの時間を費やす必要がなくなり、正しい報告チャネルをワンクリックで見つけられます。第二に、組織のセキュリティに対する積極的な姿勢を示します——security.txtがあるウェブサイトは「私たちはセキュリティを重視しており、責任ある報告を歓迎します」と言っているようなものです。第三に、脆弱性が公開されたり悪用されたりするリスクを減らします：研究者に正式なチャネルがあれば、連絡がつかないからといってTwitterやGitHubで脆弱性を直接公開することがなくなります。第四に、多くの業界規制要件（金融、医療、政府など）では、脆弱性開示チャネルの構築がコンプライアンス要件となっています。

security.txt をデプロイする際に注意すべき重要な詳細事項がいくつかあります。第一に、パスが正しいこと：標準パスは /.well-known/security.txt であり、後方互換のためにルートに /security.txt を配置することもできます。ここでの.well-knownディレクトリはRFC 8615で定義された標準の「既知のリソース」ディレクトリであり、robots.txtなどの他の標準ファイルも関連する場所に配置されます。第二に、HTTPS経由で提供する必要があり、平文HTTPは安全でないとみなされます。第三に、Content-Typeはtext/plainでなければならず、text/htmlやその他のタイプであってはなりません。第四に、security.txtに対してドメインをまたいだリダイレクトを行わないこと——https://example.com/.well-known/security.txt が https://other-domain.com/security.txt にリダイレクトされると、研究者や自動ツールはこれを疑わしいと判断します。第五に、Expiresフィールドを設定して定期的に更新することを忘れないでください。有効期限の切れたsecurity.txtは情報が信頼できないとみなされます。

Contactフィールドはsecurity.txtで最も重要なフィールドであり、本当に不可欠な唯一のフィールドです（Expiresも必須ですが、単なるタイムスタンプです）。Contactは3つのURI形式をサポートしています：mailto:はメールアドレス用、https://はWebページリンク（セキュリティ報告フォームページなど）用、tel:は電話番号用です。少なくともmailtoメールアドレス1つとhttpsフォームリンク1つを提供することを強く推奨します——フォームはボットによるスパムを防止し、メールは研究者が暗号化された報告を直接送信するのにより便利です。複数の連絡先を複数行でリストできます。例えば、セキュリティチームのメール、セキュリティ責任者のメール、第三者の脆弱性プラットフォームのリンクなどを同時に提供できます。

Encryptionフィールドはオプションですが、実務上は非常に重要です。セキュリティ研究者が深刻な脆弱性（ユーザーデータ漏洩、リモートコード実行など）を発見した場合、彼らは脆弱性の詳細を平文メールで送信したくありません——メールは送信中に複数のサーバーを経由し、そのうちのいずれかの段階で盗み見られる可能性があるからです。PGP（Pretty Good Privacy）公開鍵暗号化は業界標準の安全な通信方法です。PGP鍵ペアを生成し、公開鍵をウェブサイトに配置して（例：/.well-known/pgp-key.txt）、そのURLをEncryptionフィールドに記入するだけです。研究者はあなたの公開鍵で報告内容を暗号化し、対応する秘密鍵を持つ人だけが復号して読むことができます。

Policyフィールドはあなたの脆弱性開示ポリシー（Vulnerability Disclosure Policy, VDP）ページにリンクしており、これは研究者の信頼を構築するための鍵となります。優れたVDPには以下の内容を明確に記載すべきです：テスト範囲（どのシステムがテスト範囲に含まれ、どのシステムが含まれないか）、許可されるテスト方法（SQLインジェクション/XSSテストは許可するがDDoS/ソーシャルエンジニアリング/実ユーザーデータへのアクセスは禁止するなど）、約束された対応時間（例：「3営業日以内に報告受領を確認します」）、脆弱性賞金の提供の有無、法的セーフハーバーの約束（ルールに従った善意の研究者を訴追しないことを明確にする）など。国際的には多くのVDPテンプレートが参考にでき、米国CISAもオープンソースのVDPテンプレートを提供しています。

セキュリティ連絡自体に加えて、security.txt にはいくつかの「驚きの」フィールドがあります。Acknowledgmentsフィールドはセキュリティ殿堂入り（Hall of Fame）を構築します——脆弱性を発見してくれた研究者を公に感謝することで、彼らの貢献を認め、コミュニティ構築の一助となります。Hiringフィールドは非常に賢い設計です：あなたのウェブサイトの脆弱性を発見できる人はそれ自体が優秀なセキュリティ人材であり、security.txtに採用リンクを配置することは最も精度の高いセキュリティ人材採用チャネルとなります。多くの企業がsecurity.txtを通じて優秀なセキュリティエンジニアを採用しています。Canonicalフィールドはセキュリティ上の考慮事項です——他のドメインで攻撃者があなたのsecurity.txtを偽造することを防止します。

よくあるスパムに関する懸念についてですが、実際にはsecurity.txtをすでに導入しているほとんどの組織から、スパムの増加は顕著ではないとのフィードバックが寄せられています。これは以下の理由によります：第一に、スパム送信者は通常security.txtをクロールしてメールアドレスを入手していないからです；第二に、mailtoメールを直接配置する代わりにhttps://フォームリンクを使用し、フォームに認証コードを追加することでボットを完全にブロックできるからです；第三に、専用のセキュリティメール（security@など）には通常厳格なスパムフィルターが設定されているからです。それに比べて、セキュリティ連絡チャネルがないために深刻な脆弱性報告を見逃すことの代償は、スパムのわずかな増加よりもはるかに大きくなります。

このジェネレーターは RFC 9116 標準に厳密に従って構築されており、すべての出力フォーマットは正規化されています：Contactフィールドはプレフィックスを自動的に認識し、Expiresフィールドは標準ISO 8601 UTC時間フォーマットを使用し、Preferred-Languagesは使用している言語に応じて自動的に設定されます。生成された内容はそのままコピーして /.well-known/security.txt パスにデプロイでき、修正は一切必要ありません。また、すべての設定はブラウザローカルで完了し、いかなるサーバーにも送信されません——あなたのセキュリティ連絡先情報は常にあなたのデバイス上にのみ保存されます。security.txtのデプロイに必要な時間はわずか5分ですが、それによって構築されるセキュリティコミュニケーションチャネルは、将来的に深刻なセキュリティインシデントを回避するのに役立つ可能性があります。