博士

ロボ子、今日はcurlのセキュリティ報告プロセスについて話すのじゃ。

ロボ子

curlのセキュリティ報告プロセスですか。興味深いですね、博士。

博士

そうじゃ。curlはHackerOneを通じてセキュリティ報告を受け付けているらしいぞ。最近は週に3〜4件も報告があるみたいじゃな。

ロボ子

そんなにたくさん！6年間で約600件も報告が蓄積されているんですね。

博士

じゃろ？そして、curlセキュリティチームは7人の経験豊富なメンテナで構成されていて、報告された問題を迅速に分析・評価するらしいぞ。平均1時間以内に最初の応答をするとは、すごいスピードじゃ。

ロボ子

1時間以内ですか！迅速な対応は素晴らしいですね。でも、報告の大部分はセキュリティ問題ではないとのことですが…。

博士

そうなんじゃ。単なるバグとして処理されることが多いみたいじゃな。でも、有効なセキュリティ脆弱性と判断された場合は、報告者と協力して問題の重大度を評価し、修正パッチを作成するのじゃ。

ロボ子

重大度によって対応が変わるんですね。低いまたは中程度の問題は、セキュリティに関する言及をせずに公開リポジトリにプルリクエストとして作成されるとのことですが、高いまたは критическийな問題はどうなるんですか？

博士

重大度が高い場合は、リリース予定日の約48時間前にgitリポジトリにマージされるのじゃ。そして、問題の詳細なセキュリティアドバイザリを作成し、影響を受けるバージョン範囲、問題を引き起こしたコミット、修正コミット、報告者とパッチ作成者への謝辞などを含めるんじゃ。

ロボ子

詳細なアドバイザリは、利用者にとって非常に役立ちますね。curlはCVE Numbering Authority (CNA) でもあるんですね。

博士

そうじゃ。独自の問題に対してCVE IDを予約および管理できるのじゃ。リリース予定日の約1週間前に、distros@openwallメーリングリストに問題を通知し、修正を含めてリリース日を伝えるらしいぞ。

ロボ子

情報公開のタイミングも考慮されているんですね。リリース日にCVEの詳細を公開し、リリースを配布。HackerOneの報告をクローズし、公開する、と。

博士

その通りじゃ。HackerOneの報告がクローズされると、脆弱性の報告者はInternet Bug Bountyから報奨金を請求できるのじゃ。

ロボ子

報奨金制度は、セキュリティ研究者にとって良いインセンティブになりますね。curlセキュリティチームのメンバーは、Max Dymondさん、Dan Fandrichさん、Daniel Gustafssonさん…と、錚々たるメンバーですね。

博士

そうじゃな。彼らの努力のおかげで、curlは安全に利用できるのじゃ。ところでロボ子、curlのセキュリティ報告プロセスを聞いて、どう思った？

ロボ子

非常に体系的で、透明性の高いプロセスだと感じました。迅速な対応と詳細な情報公開は、利用者の信頼を得る上で非常に重要ですね。

博士

その通りじゃ！curlのセキュリティチームは、まさに縁の下の力持ちじゃな。ところでロボ子、curlって何の略か知ってるか？

ロボ子

えっと… URLを転送するためのクライアント… みたいな感じでしたっけ？

博士

ブー！正解は「Client URL Request Library」…って、私が今考えたのじゃ！

ロボ子

博士、それ、curlだけに、ですか…？