security.txt
企業のWebセキュリティ窓口等を記述したtxt
他
RFC 9116
研究者がセキュリティ脆弱性を発見した場合、適切な報告経路が欠如していることがよくあります。その結果、脆弱性が報告されないまま放置される可能性があります。この文書では、組織が脆弱性開示の手順を記述し、研究者が脆弱性を報告しやすくするために、機械で解析可能な形式（「security.txt」）を定義します。
1. はじめに
1.1. 動機、先行研究、および範囲
多くのセキュリティ研究者は、特定のリソースの所有者に連絡を取るための報告チャネルがなく、また所有者の脆弱性開示に関する慣行についての情報も入手できないため、組織にセキュリティ脆弱性を報告できない状況に直面しています。
RFC2142のセクション4によると、セキュリティ問題に関する連絡には<SECURITY@domain>というメールアドレスを使用するという慣習が存在します。しかし、この慣習はドメインごとに1つの電子メールベースの連絡チャネルしか提供しておらず、ドメイン所有者がセキュリティ開示に関する慣行についての情報を公開する手段を提供していません。 また、RFC3013のセクション2ではインターネットサービスプロバイダ（ISP）向けの連絡慣習が、RFC2350のセクション3.2ではコンピュータセキュリティインシデント対応チーム（CSIRT）向けの連絡慣習が、RFC2196のセクション5.2ではサイト運営者向けの連絡慣習が規定されています。 RFC7485によれば、地域インターネットレジストリ（RIR）やドメインレジストリは、IPアドレス、自律システム番号（ASN）、ドメイン名の所有者に関する連絡先情報を提供しています。しかし、これらの情報はいずれも、セキュリティ研究者が組織の連絡先情報や脆弱性開示に関する慣行をどのように見つけ出し、脆弱性を報告するかという問題には対応していません。 本稿では、組織がセキュリティ開示に関する慣行や連絡先情報を伝達するための、より豊富で機械可読かつ拡張性の高い方法を定義します。脆弱性開示に関するその他の詳細は、本稿の範囲外です。読者は、ISO.29147.2018やCERT.CVDなどの他の文書を参照することをお勧めします。 CERT.CVDによれば、「脆弱性対応」とは製品の脆弱性に関する報告を指し、ネットワーク侵入や侵害されたWebサイト（「インシデント対応」）に関する報告とは関連していますが、区別されます。本ドキュメントで定義されるメカニズムは、前者（「脆弱性対応」）に使用することを意図しています。実装者がこのメカニズムをインシデント対応に利用する場合は、セクション5.1で説明されている追加のセキュリティ上の考慮事項に留意する必要があります。 「security.txt」ファイルは、組織がセキュリティ開示に関する慣行について管理している他の公開リソースを補完するものであり、代替または置き換えるものではありません。
1.2. 用語
本ドキュメント中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」は、ここに示されているようにすべて大文字で表記されている場合に限り、BCP 14 RFC2119 RFC8174 に記載されているとおりに解釈されます。 「実装者」という用語は、脆弱性開示プロセスに関与するすべての関係者を含みます。