先駆者に聞く、「バグ報奨金制度」のメリットと課題：セキュリティ・アディッショナルタイム（15）（2/3 ページ）

　LINEの場合も、QAチームとは別に約40人体制のセキュリティ診断チームを設けるなど、一定の仕組みは整えていた。だが、「2011年にLINEアプリをリリースしてから、爆発的な規模でサービスが成長しました。サービス規模が拡大し、診断対象も大きくなっていった結果、内部のチームでの対応が限界を迎え、脆弱性を見つけ切れなくなりました」と李氏は述べる。

LINE 李明宰氏

　また、ユーザーの急増に伴ってLINEのサービスやセキュリティに対する関心も高まった。時にはJPCERTコーディネーションセンター（JPCERT/CC）経由で脆弱性報告を受けたこともあったという。「ユーザーが増えたサービスに何が求められるかといえば、ユーザーのセキュリティを確保すること。それは当然の目標」（李氏）という考えから、バグバウンティプログラムを計画したそうだ。

　サイボウズの場合も、社内の取り組みを補えるのではないかと考えたことがきっかけだった。「2010年ごろだったと思いますが、社内でツールを用いて、主なグループウェアに対する脆弱性診断を一通り行う体制を整えました。じゃあ、ここらで一度、外部の方の診断を受けてみようと依頼したら、ツールだけでは見つけられない脆弱性がたくさん出てきました。それ以前からJPCERT/CCのセキュリティ早期情報警戒パートナーシップに参加し、幾つかの脆弱性報告をもらっていましたが、それとは比較にならない数がたった1回の診断でどーんと出て、当時の開発本部長に『思った以上にダメだな』と言われたことが記憶に残っています」と振り返る。

　サイボウズはこの経験をきっかけに、手動診断を中心としたセキュリティテストの体制を整備したり、CSIRT（Computer Security Incident Response Team）を設けて脆弱性報告を受け付け、情報収集する体制を整えたりしていった。そうした機能がそろってきた時点で次のステップとして、脆弱性報奨金制度に取り組んだという。「外部の有識者は、XSSならXSSに関してそれぞれの知見、得意技術を持っています。卓越した外部の人の力を借り、今までサイボウズがやってきた手法とは違うアプローチ、探索的手法を借りてより多くの脆弱性を見つけ、それを取り入れながら、徐々に自分たちでカバーできる範囲を広げていこうと考えました」（伊藤氏）。

寄せられた報告をどう評価し、展開する？

　こうして脆弱性報奨金制度を開始した3社だが、運用の中ではどのような課題に直面したのだろうか？　3社によれば、1つは「脆弱性の評価基準とそれに見合った報奨金額の設定」、もう1つは「社内における運用体制の確保」のようだ。

　制度を設けた企業では大抵、「何を脆弱性として定義するか」「どのような基準で判断するか」を明示し、それに沿って報告内容を審査し、報奨金を支払っている。だが、その基準に何か1つの正解があるわけではないだけに、迷いもあるようだ。

　ピクシブの場合は、「セキュリティは常に向上していきたいという思いと、そうは言ってもセキュリティに割り当てる適切な予算を決めるのは難しいという葛藤がありました。バグバウンティの開始に当たっても、報奨金として適切な金額を決めるのは簡単ではありませんでした」という。

　サイボウズでは、開始から3年以上経過し、制度が成熟してきたが故の新しい悩みもある。「3年半継続していると、だんだん脆弱性の穴というのも堀り尽くされてくるんですよ。最初のころは、見つけやすく、また誰が見ても『これはまずいね』という脆弱性が多かったのですが、年月がたつとそうしたものが減ってきて、技術的に難しいもの、攻撃の前提条件がかなり絞られるものなどが増えてくる。サイボウズが基準とするCVSS（Common Vulnerability Scoring System）で測れば確かに脆弱性なのですが、開発者からすると『これって脆弱性っていえるのかな？』という、グレーゾーンの報告が増えてくるんです」と伊藤氏は述べる。

　必ずしもリスクが高いとはいえない報告の修正を、開発者も含め、どのように関係者の「納得感」を保ちながら進めていくか。1つの解決策としてサイボウズでは、技術の責任者が集まる「テックリーダーミーティング」という場で議論することにしているという。

　「CVSSで評価をすると高いスコアが出るが、現実的なリスクが低いということもあります。CVSSだけで評価するにも限界があるので、それを踏まえて、サイボウズとしてはどんなものを脆弱性として受け取るのか、みんなが納得するものを作るため、話し合いをし、事例をためながらやっています」（伊藤氏）。共通理解を作り、トリアージを容易にすることは、年に180件程度寄せられる報告にスムーズに対応するためにも必要なことだと考えているそうだ。

　また、基準を明確にし、報告者への透明性を確保することも、制度を続ける上で必要な事柄だ。

　LINEでは利用規約の中に基準を提示し、リジェクトする場合は「この理由によって、いただいた報告は残念ながらリジェクトされました」と説明するようにしている。もう1つのユニークな取り組みが「審査委員会」だ。「実際にバグバウンティを行っている人も含め、優秀なハッカーを集めた審査委員会を設けて判断しています。より多くの審査委員に議論してもらうことで判断が公平になりますし、もしリジェクトされた場合にも合理的な理由を説明できます」（李氏）。

　さらに、報告者との信頼関係も非常に重要だ。小さなことかもしれないが、やりとりに当たっては広報担当も協力し、意図がより適切に伝わるよう文面をチェックしているという。「時々、自分が報告した脆弱性の詳細を公開してもいいかというリクエストも来て、実際に何件かは公開しています。透明性の確保は重要だと思っています」と李氏は述べる。

　サイボウズの場合は「感謝祭」を開催し、実際に顔を合わせて感謝を伝える場を設けることによって、信頼関係の醸成を図っている。制度開始から3年を経て「報告される件数や支払う報奨金の額が下がってきているので、そろそろ金額や、報告者のモチベーションを上げる取り組みをしなければならないと考えています」とも述べている。

　伊藤氏はさらに、「JPCERT/CCなどの手も借りながらCVSSなど脆弱性の影響を計測する仕組みそのものを改善することも必要だろう」と指摘する。また、「CSIRTの世界における日本シーサート協議会のように、ざっくばらんに情報を交換できる『バグバウンティ友の会』のような場があってもいいかもしれない」と述べた。「そもそも届け出られた脆弱性情報は非公開情報なのですが、自社だけでは判断に迷うことがあります。例えば『こんな内容の届け出を受けたんですが、御社だったら脆弱性として認定しますか？』といった具合に、安全に情報を共有したり、相談できる場があるとうれしいのですが」（伊藤氏）。