GitHubで脆弱性の報告をしてみたが体験が良かった話
セキュリティエンジニア兼SRE兼サーバサイドエンジニアの@okazu_dmです。今回は、GHSA便利、という話をします。
これはなに？
WebアプリケーションフレームワークのHonoに脆弱性を報告したときに、GitHubの機能であるGHSA(GitHub Security Advisories)を初めて使ったのですが、体験が良かったので脆弱性を見つけてから公開されるまでの流れをまとめました。
脆弱性そのものの詳細については、以下で公開しています。
以下のドキュメントに書いてある以上の情報はないです。
脆弱性を見つけたとき: 報告
まず、リポジトリのSecurityタブから以下の画面に行けますが、ここから Report a Vulnerability ボタンを押します。
すると以下のようなフォームになるので、あとはフォームを埋めていくだけです。
地味に、ボタンを選択していくだけでCVSSのスコアの計算を自動でやってくれる機能が便利でした。
フォームを送信するとadvisoryが作成されるのですが、これはまず最初にtriageというステータスになり、この状態でリポジトリのオーナー等による確認を待ちます。
advisoryが公開されるまでは、このadvisoryを見れる人はWrite権限があるユーザに限られます。
余談ですが、具体的な脆弱性の内容や攻撃手法がわかっていても、人に説明するのは(特に非母語では)面倒なものですが、ある程度の内容をChat GPTに食わせるとフォーマットに合わせて体裁整えつつ英訳してくれるので、非常に楽になりました。
(必須ではないが)PRの作成
これが一番便利だと思ったのですが、上記の手順でadvisoryを作成すると、その画面からプライベートフォークを作って、PRを出すことができます。
このプライベートフォークは、元のリポジトリに紐づく形でコラボレーターの設定がされた状態でフォークされるため、advisoryを見れる人に限定されます。
この状態で、PRを作成すると非公開の状態でレビューが受けられるので、そこである程度意図のすり合わせができて脆弱性についての説明にもなり便利でした。
ただし、CIが走らない点は面倒です(とはいえ、CIを通じて脆弱性情報が外部に公開されるリスクを避ける上で当然の設計ですが)
コントリビューターとの調整
advisoryを作成してしばらくしたら、(おそらく一般的には)コントリビュータが確認してくれてコメントが入ります。
今回は他のライブラリの挙動などを考慮してHonoではどのような方針にすべきか、などという一般的なPRの話や、脆弱性情報の公開前後の流れの確認などをいくつかして終わりました(幸い脆弱性そのものの仕組みや、緊急度等についての議論は発生しませんでした)。
今回は、Honoメンテナの方々に丁寧かつ早く対応していただけたため、PRのレビュー含めて2日程度(こちらでPRを修正している時間を除けばもっと短かった)で公開できました。
ここまでのステップが普段使っているGitHubのUIで行われるため、操作で何か不明な点はなくスムーズに行えたのは体験としてかなり好印象でした。
公開
脆弱性に関する情報や、それに関する調整で特に問題がないと判断されれば、リポジトリのオーナー/管理者等によってadvisoryが公開されます。
これで、以下のように他のユーザからも見れるステータスに更新されます。
ちなみに、advisoryを提出したユーザ(また、おそらくWrite権限があるユーザ)からは、当時のコミュニケーションの履歴が見れることがわかりました。
また、脆弱性情報として公開したあとにCVE番号の割り振りをリクエストしてもらうことも可能です。
感想
- Honoのメンテナの方々が素早く丁寧に対応していただけたので圧倒的感謝🙏
- 脆弱性の報告、メンテナとのコミュニケーション、コード修正の提案、CVEの割り振りなどがGitHubの中で完結するので、かなり楽
- OSSの脆弱性を見つけたのは初でしたが、自分でPR出せる分、業務上の報告などよりは説明しやすくて体験が良い
Discussion