【ITニュース解説】security.txt in ten minutes: the cheapest Cyber Resilience Act task

システムエンジニアを目指す皆さんにとって、ソフトウェアやサービスのセキュリティは避けて通れない重要なテーマだ。特に、自分が開発したプロダクトにセキュリティ上の欠陥（脆弱性）が見つかった場合、それを発見してくれた人、つまりセキュリティ研究者とどうコミュニケーションを取るかは非常に大切になる。もし、あなたのプロダクトでバグを見つけた研究者が「これをどこに報告すればいいんだろう？」と迷ってしまったら、そのバグは適切な部署に届かず、公の場に晒されたり、悪意のある人物に悪用されたりする可能性も出てくる。

そこで役立つのが、「security.txt」というシンプルなテキストファイルだ。これは、ウェブサイトの特定の場所（具体的には「/.well-known/security.txt」というパス）に配置される、誰でもアクセスできるファイルで、セキュリティ研究者が脆弱性を報告するための公式な連絡先や、関連するポリシーなどの情報を提供するものだ。難しいフレームワークや複雑な設定は一切不要で、たった数行のテキストファイルを作成してウェブサーバーに置くだけで、この「連絡先がわからない」という問題を解決できる。

security.txtファイルは、RFC 9116という国際的な技術標準によって定義されており、基本的な情報として主に三つのフィールド（項目）で構成される。一つ目は「Contact」だ。これは、脆弱性を報告したい人が連絡を取るべきメールアドレスや、専用の報告フォームへのURLなどを指定する。例えば、「mailto:security@example.com」のように、セキュリティ担当部門のメールアドレスを記載する。二つ目は「Expires」で、このファイルの有効期限を示す日付だ。この日付を過ぎると、ファイルを自動的にチェックするツールなどからは「古い情報だ」と判断されるため、定期的な更新が必要になることを示唆している。そして三つ目は「Canonical」で、このsecurity.txtファイルが配置されている正確なURLを指定する。これは、例えばコンテンツ配信ネットワーク（CDN）を使っていたり、ミラーサイトがあったりする場合に、このファイルがどこから提供されている正規の情報源なのかを明確にするためのものだ。これらの情報を記述したテキストファイルを、自分のウェブサイトの静的アセット（画像やCSSファイルなど、サーバーがそのまま配信するファイル）と同じように配置し、デプロイするだけで、設定は完了する。特別なビルドプロセスや、外部のソフトウェアに依存することもないため、非常に手軽に導入できるのが特徴だ。

現在、security.txtの設置は「良い慣行（グッドプラクティス）」とされており、導入が推奨されている状態だ。しかし、この状況は間もなく変わる予定だ。2027年12月11日からは、欧州連合（EU）で施行される「Cyber Resilience Act（CRA：サイバーレジリエンス法）」という新しい法律によって、その一部が義務となる。CRAは、デジタル製品のセキュリティを向上させることを目的とした法律で、製品が市場に出る前から、そのライフサイクル全体を通じて一定のセキュリティ要件を満たすことを求めるものだ。

このCRAの付属書IのパートIIには、製品の脆弱性への対応に関する必須要件が具体的に示されている。その中のポイント5では「協調的な脆弱性開示ポリシー（Coordinated Vulnerability Disclosure Policy）」の存在が求められ、ポイント6では、ユーザーや研究者が脆弱性を報告するための「連絡先アドレス」を持つことが求められている。security.txtファイルに有効な「Contact」フィールドを記載しておけば、このポイント6の要件を単独で満たすことができる。一方、ポイント5の「協調的な脆弱性開示ポリシー」は、もう少し踏み込んだ内容が必要となる。これは、報告された脆弱性をどのように評価し、優先順位をつけ、対応していくのか、報告者に対していつまでに何らかの返答をするのか、脆弱性を修正した際に報告者の名前を公表するのか（クレジットを付与するのか）など、具体的なプロセスや約束事を定めた方針書だ。このポリシーは、security.txtファイルの「Policy」フィールドを使って、そのポリシー文書が公開されているURLをリンクすることで、研究者からアクセスできるようにできる。

CRAによる罰金は、この記事が書かれた時点ではまだ適用されていないが、2027年12月11日から、他の付属書の規定と同じタイミングで適用が開始される。罰金は、企業の年間売上の最大2.5%または最大1,500万ユーロにも及ぶ可能性があるため、非常に重い。security.txtファイルの設置は10分程度で済む簡単な作業だが、その背後にある脆弱性開示ポリシーをきちんと作成するには、もっと長い時間と検討が必要だ。締切ぎりぎりになってポリシー作成を始めるのは間違いであり、まずは簡単に設置できるsecurity.txtファイルから着手し、並行してポリシーの策定を進めることが賢明な戦略となる。

セキュリティ研究者がなぜsecurity.txtファイルをこれほど重視するのかというと、それは彼らにとって非常に効率的で信頼性の高い情報源だからだ。もし、ある研究者があなたのプロダクトで脆弱性を見つけたとする。彼らが連絡先を探す際に、security.txtファイルがあれば、迷うことなく直接の連絡先情報が得られる。さらに、「Expires」フィールドを見れば、そのファイルが定期的にメンテナンスされていることがわかり、情報が古くないという安心感を得られる。もし「Policy」フィールドもあれば、報告後のプロセスや、どのような対応が期待できるのかも事前に把握できるため、安心して報告を進められるのだ。SecurityTxt.orgのようなオンラインバリデーターツールや、各種の脆弱性開示プラットフォームは、人間が報告内容を読む前に、まず自動的にこのsecurity.txtファイルが存在するかどうかをチェックする。

もしsecurity.txtファイルが存在しない場合、研究者は適切な連絡先を推測するしかなくなる。その結果、研究者は連絡を諦めてしまったり、あるいは最悪の場合、発見した脆弱性を公共のフォーラムやSNSに投稿してしまったりする可能性もある。これは、企業にとっては非常に危険な事態だ。正式な報告経路が用意されていないことで、世間に脆弱性が公表されてから初めて企業がその存在を知る、といった「ゼロデイ攻撃」のリスクが高まることにも繋がりかねない。

ただし、security.txtはあくまで「脆弱性をどう報告するか」という問いに答えるものだ。CRAが自分の製品に適用されるのかどうか、あるいは自分のプロダクトが依存しているオープンソースライブラリなどにどんな脆弱性があるのか、といった、より根本的で複雑な問題に答えるものではない。これらの問いは、CRAの協調的な脆弱性開示ポリシーがそもそも自分たちの製品に適用されるのかを判断するために、先に解決すべき問題となる。

システムエンジニアとして、今後セキュリティに関わる機会は増える一方だ。まずは、この非常に簡単なsecurity.txtファイルの設置から始め、自社のプロダクトがセキュリティ研究者にとって報告しやすい環境を整えることが、最初の、そして最も安価なサイバーレジリエンス強化への一歩となる。そして、その背後にある本格的な脆弱性開示ポリシーの策定へと繋げていくべきだ。これは単なる法律遵守だけでなく、自社製品の信頼性を高め、ユーザーの安全を守るための重要な取り組みであると理解してほしい。