A File Format to Aid in Security Vulnerability Disclosure - 正しくつながる第一歩 - JPCERT/CC Eyes

早期警戒グループの戸塚です。早期警戒グループでは、注意喚起や早期警戒情報といったセキュリティ情報や、JVNアドバイザリの発信を行っています。私は、脆弱性コーディネーターとして、セキュリティ研究者などの脆弱性発見者からJPCERT/CCに報告された脆弱性関連情報に基づいて、対象製品の開発者と対策策定などの調整をし、JVNアドバイザリの公表に至る一連のコーディネーション業務を担当しています。この記事では、脆弱性コーディネーターの視点から、脆弱性調整を行う機関や脆弱性発見者が開発者との連携をしやすくするために、開発者組織が実施可能な対策の一つとして、今年、2022年4月に正式公開された「RFC 9116：A File Format to Aid in Security Vulnerability Disclosure」[1]を紹介します。

私が担当する脆弱性調整においては、報告された脆弱性関連情報を製品開発者に通知し、確認して対応いただくことが重要です。この際に最初の課題となるのが、製品開発者とのファーストコンタクト（連絡先とその内容を適切に設定し、連絡すること）です。情報を送ることができればなんでもいいというわけではなく、まず、課題を認識していただける適切な連絡先を見つけなければなりませんし、初めての相手に私たちの調整活動を理解していただく必要もあります。脆弱性調整において正しい調整先にたどり着けないと、報告された脆弱性関連情報に対して適切な対策が施されません。脆弱性関連情報が適切に製品開発者に渡り、対策が施され、対策情報とともにアドバイザリが公表される、あるいは発見者からの報告が開示される、つまり脆弱性関連情報の適切な情報流通がなされることが望ましいのですが、もし正しい調整先にたどり着けなければ、最初から失敗となってしまいます。そうした場合、製品ユーザーがゼロディ攻撃の脅威にさらされるリスクが残りますし、製品開発者は自身の製品がサイバー攻撃に悪用されることで、製品に対する信頼が損なわれる可能性もあります。JPCERT/CCでは、製品開発者とのファーストコンタクトにおいて、安全かつ確実に情報を受け取ってご確認いただけるように、連絡先の選定に関して次のことに気をつけ、開発者や製品のWebサイト上で連絡先を探しますが、どうしても探し当てられないときには、JVNの「連絡不能開発者一覧」[2]に掲載し、開発者情報の公開調査を行うこともあります。

不特定多数に開示されない（OSSのissue報告メーリングリストなどはNG）
開発者組織内の脆弱性への対策策定に責任がある部門、メンバに届く(購入相談窓口など明らかに異なる目的の連絡先は避けたい)
暗号通信など安全な通信手段が使える（脆弱性情報は基本的に平文で送らない）

開発者や製品のWebサイト上を探しても、すべての製品開発者が、脆弱性を受け取る準備ができているわけではありません。製品コンタクトやサポートの窓口や考え方も千差万別です。中には、私たちからの連絡を受けて組織内で対応部門を探すうちに何か月も経過し、最終的に応答がなくなってしまうケースもありますし、脆弱性対応経験のない製品開発者の場合は、JPCERT/CC？何者？と不審に思われ、対応しないと拒否されてしまうケースもあります。また、OSSなどの製品開発者では、公開のメーリングリストに脆弱性関連情報を投稿して欲しいと依頼されるケースもあります。その方が効率的に情報を共有できるかも知れませんが、私たちとしては送った情報が適切に保護されることを優先して調整を進めています。

脆弱性対応に関して製品開発組織内でまったく準備ができていない場合は別として、少なくとも脆弱性対応窓口があるのならば、それを”外向けにわかりやすく”示しておくことで、想定外の窓口に連絡されて適切な窓口が脆弱性関連情報を受け取れないといったトラブルを防止できます。対JPCERT/CC向けには「製品開発者登録」[3]という方法がありますが、この詳細はJPCERT/CCのWebサイトをご覧いただくこととし、ここでは、JPCERT/CCからだけでなく広く外部から安全かつ確実に情報を受け取るための方法である「RFC 9116：A File Format to Aid in Security Vulnerability Disclosure」を紹介します。

組織がセキュリティ関連情報の通信を行う際に利用すべきメールアドレスとして、既存のRFC2142[4]にての利用が推奨されています。他にもISPやCSIRT向けに連絡先について定義したRFCもありますが、いずれも脆弱性発見者が開発者組織に脆弱性報告を行うため、適切な連絡先と対象組織の脆弱性開示ポリシーを確認し、送り手と受け手においてコミュニケーションを確立する上で必要な情報は十分ではなかったと言えます。

RFC9116は、組織が脆弱性の開示方法を説明し、セキュリティ研究者などが発見した脆弱性を報告しやすくするために定義されたものです。この仕組みは単純で、必要な情報を記載した「security.txt」ファイルをWebサイトの「/.well-known/」パスの下に公開することを要求しています。「security.txt」には次の項目が記述されます。

コンタクト：電子メールアドレス、電話番号、連絡用フォームのアドレスなどの連絡先や方法
例：
Contact: mailto:security@example.com
Contact: tel:+1-201-555-0123
Contact: https://example.com/security-contact.html
有効期限：この「security.txt」の有効期限
例：Expires: 2023-03-31T18:37:07z
謝辞：セキュリティレポーターへの謝辞記載場所等
例：Acknowledgments: https://example.com/hall-of-fame.html
カノニカル：この「security.txt」の正式配置場所（URI））
例：Canonical: https://www.example.com/.well-known/security.txt
暗号化鍵：脆弱性報告時に使用できるOpenPGP公開鍵などの掲載場所等
例：Encryption: https://example.com/pgp-key.txt
採用情報：当該ベンダーのセキュリティ関連の人材募集内容の記載場所等
例：Hiring: https://example.com/jobs.html
ポリシー：当該ベンダーのセキュリティポリシーの記載場所等
例：Policy: https://example.com/disclosure-policy.html
優先言語：受け付けるセキュリティレポートの言語
例：Preferred-Languages: en, es, fr

「security.txt」作成をサポートしてくれるウェブサイト[5]もあり、気軽に「security.txt」作成を試してみることができます。「security.txt」では、「コンタクト」と「有効期限」だけが必須入力項目となっており、私たちが日々感じているのと同様に、相手の組織に対して連絡する際には、「今」正しく繋がる連絡先を欲している人たちが少なからずいるのだと改めて思いました。オプショナルな項目に採用情報があるのもユニークで、組織にとってもリサーチャーを求める方法の一つとなるかもしれません。いずれにしても、本方式は、ライトウェイトに世界中のセキュリティ研究者などの脆弱性発見者や調整機関にベンダー（開発者組織）の有効な連携先を示すことができるものであると感じます。また、ベンダーのセキュリティ・脆弱性対応の成熟度向上に合わせて内容の充実を図れることも利点だと思いました。

コーン・フェリーとFORTUNE誌による『世界で最も賞賛される企業 2022』[6]の全業界トップ50でsecurity.txtを掲載しているサイトを確認したところ、電子メールアドレスのみの企業から電子署名付きで全項目掲載している企業まで、11社の掲載が確認できました[7]。それら11社のほかに、GitHubやWordPress、Facebookといった企業も掲載しています。（JPCERT/CCの「製品開発者登録」に登録いただいている組織のいくつかを抜粋で確認した限り、残念ながら掲載されている例はありませんでした。）

今年4月に正式公開されたばかりで、まだ日本では掲載している組織は少ないようですが、ベンダーが善意のセキュリティ研究者や脆弱性報告者と正しくつながる第一歩として、「security.txt」の導入を検討してみてはいかがでしょうか？

早期警戒グループ戸塚紀子

参考情報

戸塚紀子（Noriko Totsuka）

長年、ベンダーのPSIRT業務に携わった後、2021年4月に、脆弱性関連情報の調整業務担当としてJPCERT/CCに入社。早期警戒グループにて、主として海外ベンダとの調整業務をしております。