脆弱性発見報奨金制度の運営ノウハウや苦労話を本音で語るLINEとサイボウズの対談。第1回はプログラムの準備、第2回は審査や報奨金の決定過程を紹介したが、第3回は外部のバグハンターとのコミュニケーションにおける苦労話を紹介する。
記者 報奨金プログラムでバグハンターとやり取りする過程で、どのような点に苦労しましたか。
サイボウズ伊藤氏 まず、マンパワーという点で一番大変だったのは、報奨金プログラム本体ではなく、2014年8月上旬に実施した「バグハンター合宿」（関連記事：サイボウズが実施した「バグハンター合宿」）でした。2日で50件以上の脆弱性報告を評価しました。
通常の脆弱性プログラムでは、評価結果をメールで報告するため、幾分余裕があります。一方でハンター合宿では、その場で評価を伝えないといけません。バグハンターの皆さんの顔色を伺いつつ評価を伝えるわけで、運営側のプレッシャーは大きかったですね。
ちなみに、合宿の場にはサイボウズの社員もいたので、非常にソーシャルハッキングがしやすい環境でした（笑）。「社員とのコミュニケーション」という名の下に、バグハンターの皆さんが協力した結果、脆弱性が見つかったことはありましたね。あれは面白かったです。
記者 え。それは、社員が実装時に見つけた脆弱性を漏らしたとか？
サイボウズ佐藤氏 社員も脆弱性自体は当然知りません。バグハンターの皆さんは「サイボウズ社内ではどのような試験を既にやっているのか？」といった話を聞き出して、「ここにはまだ穴がありそうだ」といったヒントをつかんだそうです。
社員によれば、バグハンターの皆さんと一緒に一緒にランチを食べながら、なんとなく殺気を感じたとか（笑）。
記者 バグハンターとのやり取りに当たって、想定外のケースはありましたか。
伊藤氏 お恥ずかしい話なのですが、脆弱性と1回は認定して、いざ修正しようとした結果、最終的に「これは脆弱性ではない」と結論付けたケースがありました。これは社内の脆弱性ハンドリング体制の都合なのですが、このとき報告者にどう報告したらいいものか、大変苦労しました。
記者 端的にいえば「このバグは仕様です」といったケースでしょうか。
伊藤氏 「仕様です」になるケースも確かにあります。あるいは、脆弱性の認定はしたものの、製品チームの観点からはセキュリティリスクが高いとは考えにくく、改修の優先度が低いため、最終的にリジェクトするケースもあります。
例えば、漏えいする情報が極めて少ない場合や、元々システムとして許容しているケースもあります。
こうしたグレーの領域では、脆弱性の報告者に説明する際のルールをあらかじめ作っておかないと、いざというときにうまく説明できません。サイボウズの場合、最初に短期のプログラムを実施した際にこうした経験をしたので、次のプログラムでは説明のルールを盛り込むことができました。
佐藤氏 セキュリティチームの観点からいえば「見えるべきではないものが見える」のが脆弱性です。
ただ製品チームからすると、見えたものが全く重要でない情報だったり、その操作をするには管理者権限が必要だったりした場合、それは脆弱性と言えるかどうか？と考えるのです。
そもそも管理者権限が奪われれば、脆弱性にかかわらず、あらゆる情報が盗めるので、脆弱性と評価する意味がありませんし。
記者 ちなみに、脆弱性の判断基準の話が出たのでLINEさんに聞きたいのですが……あの週刊誌ネタにもなったクローンiPhoneの件は、脆弱性に含まれるのでしょうか。
LINE中村氏 ここで、すごい質問を突っ込んできましたね（笑）。
LINE広報 LINEとしては、あの問題はiPhoneの仕様上の問題と考えており、脆弱性とは考えていません。弊社のアプリだけに起こるものではありません。
2016年2月22日に、複数の端末から同時アクセスできないよう仕様を変更しましたが、これもあくまで「仕様の変更」です。
