こんにちは、Cy-PSIRTの長友です。今回は、「脆弱性報奨金制度に参加したいけれど一歩が踏み出せない」という皆さんに向けて、制度への参加方法と報告時のポイントをお伝えしようと思います。
この記事はあくまで弊社の考える始め方やポイントであって、他社の制度に報告される際はそれぞれのルールや報告方法を熟読したうえで報告されることをお勧めいたします。

脆弱性報奨金制度とは

セキュリティ上問題があると思われる挙動を見つけて報告をしていただき、脆弱性として認められるとその深刻度に応じて報奨金をお支払いする制度のことです。弊社では2016年度から毎年少しずつルールを変更し、実施しています。
この制度は、バグバウンティと呼ばれていることもあります。
ちなみに、バグを見つけてたくさんの報奨金を稼いでいるかたもいらっしゃるようです。（参考：サイボウズが自社製品のバグに懸賞金を出す理由って？──バグハンター合宿に密着取材してきた）

脆弱性報奨金制度に参加するには

まずは、脆弱性報奨金制度を実施している企業や団体を探しましょう。
弊社は、こちらのページでご案内をしています。
以下のプラットフォームで探してみると、弊社以外にも様々な分野の企業・団体が脆弱性に報奨金を支払っていることが分かるかと思います。

興味を持った制度が見つかったらルールや注意事項、手続きのフロー、セキュリティに関連する法令などをよく読んで理解しておきましょう。
たとえば、弊社の脆弱性報奨金制度では、本番環境に影響を与えずに脆弱性を探していただくために検証環境提供制度を実施しています。こちらの環境を利用していただくことで、安心して脆弱性を探すことが可能となっています。

脆弱性を探してみよう

やってみたい報奨金制度を見つけ、ルールや注意事項の確認や必要な手続きが済んだらさっそく脆弱性を探してみましょう。
たとえば、実際にサービスを触ってみながら、挙動や通信の内容をじっくり観察してみると、なにか違和感や気になることが出てくるかもしれません。その気になる箇所に対してさまざまな攻撃手法を試してみるともしかしたら脆弱性が見つかるかもしれません。地道な作業ではありますが、ハマるととても楽しかったりもします（私も業務で弊社の製品に対して脆弱性検証をしていますが、リクエストを観察したり気になるところをつついていると時間を忘れて没頭してしまうことがよくあります）。
OWASP Cheat Sheet SeriesやHackerOneで公開されている脆弱性のレポート、PortSwigger Researchなども参考になるかもしれません。また、過去に報告した脆弱性を公開している方々のブログなどもとても参考になるでしょう。

脆弱性を報告しよう

いざ脆弱性と思しき挙動が見つかったら、報告をしましょう。
ここでは、サイボウズにご報告いただく際のフォーマットについてご説明します。ある程度このフォーマットに沿ってご報告いただきますと、弊社としては迅速な対応が行いやすくなります（いただいているお問い合わせの件数にも左右されますので、必ずしもすぐに返答できるわけではないですが……）し、報告者の方も脆弱性の整理がしやすくなるかもしれません。また、報告者・受付側で脆弱性に対する認識の齟齬が出にくくなり、適切な評価にも繋がるのでは、と考えています。

1. 脆弱性が再現する手順と環境を整理しましょう

まずは発見した脆弱性を再現させるための手順と、再現できた環境をまとめましょう。
環境に関しては、使用したブラウザ、OSは最低限あるとよいですが、もしそれ以外に何かソフトウェアを使ったのであればそれらも列挙してください。
また、脆弱性を確認した製品名と動作環境（クラウド版／Windowsオンプレミス版／Linuxオンプレミス版）、製品のバージョン（分かる場合は）も記載してください。
手順は1つの操作を1つのステップにまとめて記載するとよいでしょう（読みづらい場合はいくつかの操作をひとまとめにしてもよいかもしれません）。

例：
ブラウザ：Internet Explorer
OS：Windows 10
製品名：ガルーン(クラウド版)　4/1 時点の最新版
① スケジュールの登録画面を開く
② タイトル欄に以下の文字列を入力する

'><script>alert(1);</script>

③「保存」ボタンをクリックする
④ 保存されたスケジュールを開くと、JavaScriptが動作する

また、リクエスト内の値を変更する必要がある場合は、変更後のリクエストとレスポンスそのものや、値を変更するパラメータ名を記載するとさらに分かりやすくなります。
「いやいやそんな細かく書かなくてもわかるでしょう」と思われるかもしれませんが、詳細に書いていただくと、受付側で問題点の把握がスムーズに行なわれたり、そのあとのコミュニケーションコストがぐっと下がったりする可能性が出てくるので、ぜひ詳細に書いていただけるとうれしいです。

2. なぜ脆弱性と判断したのか簡単にまとめましょう

操作だけでも十分といえば十分なのですが、これになぜ脆弱性と判断したかの理由を記載いただくとより分かりやすい報告になるのではと考えています。先ほどの例であれば「開発者の意図しないJavaScriptが挿入されるため、脆弱性と判断した」といったところでしょうか。これを記載することで、報告側・受付側で「何が問題になるか」の齟齬が発生しなくなることにより、納得感のある評価につながりやすくなると考えているからです。その挙動の何が問題なのかを端的に表現していただけるととてもありがたいです。手順などが込み入った報告になればなるほど、この説明が重要になってきます。