JPCERT/CC Eyes

早期警戒グループの戸塚です。昨年（2022年）8月に「A File Format to Aid in Security Vulnerability Disclosure - 正しくつながる第一歩」[1]で、同年4月に公開された「RFC 9116：A File Format to Aid in Security Vulnerability Disclosure」[2]を紹介しました。本記事では、その続報を2つお届けします（RFC 9116自体や私の業務との関係に関しては、2022年8月の記事をご確認ください）。

1つ目は、RFC 9116のおかげで開発者との脆弱性関連情報のコーディネーション（調整）が大変スムーズにできた事例です。

開発者との調整では、連絡しても応答がもらえないケースが少なくないことは昨年8月の記事でも書きました。このような場合、別の連絡先があればそちらにも連絡を試みます。今回、RFC 9116が役立ったのは、私の前任者が対象製品の開発元日本法人に対して、脆弱性関連情報を渡すのに適切な連絡先を日本語の電子メールで送付し、応答がもらえないまま10カ月近くが経過していた案件でした。私は昨年来、製品開発者の連絡先を探す際には、開発者や該当製品のサイトに「/.well-known/security.txt」が置かれているか否かの確認を心がけていましたが、置かれているケースはまだまだ稀でしたので、この案件でも期待せずにアクセスしてみたところ、以下の情報が記載された電子署名付きの「security.txt」がありました。

• コンタクト：電子メールアドレス
• 暗号化鍵：脆弱性報告時に使用できるOpenPGP公開鍵
• 優先言語：英語
• カノニカル：この「security.txt」の正式配置場所（URI）
• 採用情報：当該ベンダーのセキュリティ関連の人材募集内容の記載場所

これらの情報から、この開発者へは、英語で問い合わせ内容を記述し、指定された電子メールアドレスに公開鍵暗号を使って連絡すればいいことが明確にわかりました。前任者が担当した当時は「security.txt」はなかったかもしれませんが、この再調査で、日本法人に日本語で連絡したのは、開発者が希望する連絡方法ではなかったということが判明しました。そこで、すぐに指定された方法で脆弱性関連情報の詳細を送付し、応答をいただくことができました。それから、修正対応やJVN (https://jvn.jp/, https://jvn.jp/en/) でのアドバイザリ公表の調整が進み、約半年後にアドバイザリを公表して対応完了することができました。JVNでのアドバイザリ公表まで半年という時間はかかりましたが、詳細を送ってから開発者との連絡は途切れることなく、開発者側のスケジュール変更やその理由などもきちんと共有されていたためスムーズに対応できました。

このように「security.txt」が公開されていると、脆弱性関連情報の適切な連携先が把握できるため、連絡先の正当性確認という事前の手続きが不要で、最初から適切な相手と実質的な調整を開始できます。実際にこのケースを担当し、連絡先の調査や確認の作業が軽減される経験をしたことで、逆にこれらの事前手続きがいかにストレスとなっていたかを実感しました。同じことは、自らが検出した脆弱性を開発者に報告しようとする研究者たちにも言えるでしょう。「security.txt」があれば、報告者のストレスが減り、適切な先に正しくつながる機会が増え、脆弱性の放置が減り、報告者はもとより、開発者・製品利用者にとって望ましい状況に近づけると思います。

2つ目は、10月25日に日経クロステックに「security.txt」の紹介記事[3]が出たことをお知らせします。

この日経クロステックの記事は、楽天グループが2023年10月2日にWebサーバーに「security.txt」を設置し、VDP（脆弱性開示プログラム）を開始したことで、「security.txt」に注目して書かれたものです。担当記者の方が上記ブログ[1]をご覧になり、JPCERT/CCも取材を受けました。

「security.txt」の役割とメリットは何か、日本企業での導入が少ない理由や普及のポイントをどう考えているか、「security.txt」によって開発者と脆弱性報告者が直接つながることで「情報セキュリティ早期警戒パートナーシップガイドライン」（以下、「ガイドライン」とする）による届け出制度の役割が変わるのかなど、さまざまな側面から質問を受けました。JPCERT/CCとしては、国内に「security.txt」を導入する企業が増えることで、「ガイドライン」による届け出制度以外でも脆弱性関連情報が適切に扱われる機会ができ望ましい状況になると考えていますし、「ガイドライン」の示すJVNでのアドバイザリ公表等の部分での連携には、JPCERT/CCも協力できるため、この普及を推進したいと説明させていただきました。詳細は、日経クロステックの記事をご覧ください。

最後に、今回楽天グループが導入したことで少し注目を浴びている「security.txt」ですが、これを契機に導入を検討し、実際に導入する国内企業が増えることを期待します。導入するには、そこに届いた報告を社内で適切に対応できる体制が必要になるので、簡単とは言えないかもしれません。しかし、脆弱性対応に責任をもって取り組むことを「security.txt」導入により対外的に示すことは、自社製品とその利用者を守ることにつながると信じます。何より、脆弱性関連情報の不本意な拡散や悪用を防止する効果があるでしょう。低コストで始められる「security.txt」の導入をぜひ検討してください。

[1] A File Format to Aid in Security Vulnerability Disclosure - 正しくつながる第一歩：https://blogs.jpcert.or.jp/ja/2022/08/rfc9116-introduction.html
[2] RFC 9116：https://www.rfc-editor.org/rfc/rfc9116
[3] 楽天が公開サーバーにテキスト設置、セキュリティー向上に役立つ「security.txt」：https://xtech.nikkei.com/atcl/nxt/column/18/00001/08552/ （全文は有料会員限定）