短期間に大勢の調査員が製品を精査することを目的としたプログラムもある。例えば、米Mozillaは、7月31日にリリース予定の「Firefox」の「証明書検証ライブラリ」で欠陥を見つけた場合は、1万ドルの報奨金を支払うとしている。一方、単に注目を集めることを目的としたプログラムもある。典型的な例は掲示板サイト「4chan」で、1つの欠陥に支払われる報奨金は20ドルと小額だ。

　米サンフランシスコを拠点とした米GitHubでセキュリティ部門のバイスプレジデントを務めるショーン・ダベンポート氏は、社内で公式なバグ報奨金プログラムに取り組むための支援を行った。以前は、提出プログラムを実施していた。GitHubが提供している報奨金は100ドルから5000ドルと幅がある。報奨金の金額は、脆弱性の重大度を評価した後GitHubの対応チームが確定する。

　ダベンポート氏によると、運用開始から5カ月になるバグ報奨金プログラムはGitHubのセキュリティによい影響をもたらしているという。また、セキュリティ調査員が脆弱性を見つけるときに発揮する想像力に感銘を受けたとし、同社のバグ報奨金プログラムのWebサイトでその詳細を公開している。

　「エゴー・ホマコフさんから提出されたリポートでは、重大度の低い複数の小さなセキュリティの問題を連鎖させると、非常に重大な問題に発展したという報告があった。これは調査員の豊かな想像力について考えたときに間違いなく最初に思い浮かぶ例だ」（ダベンポート氏）

バグ報奨金プログラムを外部委託するメリット

　GitHubのバグ報奨金プログラムの準備をしているとき、ダベンポート氏はMozillaなどで実施して成功を収めているバグ報奨金プログラム運営企業の担当者に問い合わせたという。そこでは、ある的確なアドバイスを得ることができた。そのアドバイスとは、「最初の数週間は悪夢のような状態になることを覚悟すべきだ」。

　“悪夢のような状態になる”のは、最初の数週間に膨大な件数のバグが提出されることに対して企業の準備が整っていないからだとダベンポート氏は指摘する。提出された全てのバグはその妥当性を検証する必要がある。同氏によると、GitHubは、このような状況に対応できる優秀な開発者を抱えていたという。だが、セキュリティスタッフが不足している企業では、突如提出されるバグと、そのバグを調査しなければならない状況への対応に悪戦苦闘する可能性がある。

　ダベンポート氏は当時を振り返って次のように話す。「当社は対応に追われていたが、最初の数週間に提出された大量のバグを遅れずに処理し、バグを解決することができた。だが、報告されたバグを選別するのに十分なリソースを持ち合わせていない小さな企業は、対応に苦労するだろう」

　数が増えているバグ報奨金プログラムベンダーが提供する最大の価値は、「脆弱性を選別することだ」とダベンポート氏はいう。このようなサードパーティーは、企業が簡単かつ効率的に報奨金プログラムを作成して管理するためのサポートを提供する。

　サンフランシスコを拠点とするバグ報奨金プログラムベンダーの米BugcrowdでCEOを務めるケーシー・エリス氏は、ダベンポート氏の考えを支持する。その上で、「セキュリティコミュニティーは脆弱性を見つけることを得意としているが、脆弱性を修正する能力はそこまで高くない」と補足する。

　Bugcrowdは脆弱性の提出を収集するインフラを顧客に提供している。だが、同社のサービスを利用している顧客の大半は「トリアージサービス」を選ぶという。つまり、顧客のセキュリティチームは脆弱性の妥当性と提出の範囲を確認するプロセスを外部委託していることになる。

　最初の数週間に発生する雑音を削減するため、Bugcrowdの顧客はセキュリティ調査員の特性に基づいてバグの提出範囲を制限することができる。調査員の特性は、Bugcrowdが実施しているプログラムで過去に調査員が提出した脆弱性の量と妥当性に基づいて算出される。

　「当社の顧客が受け取るのは、確認と修正が必要な精査されたバグの一覧だ」とエリス氏はいう。一部の企業は、バグ報奨金プログラムを全世界に対してすぐ公開している。バグの数が徐々に増えていくのを横目で見ていることはない。基本的にバグの報奨金プログラムで行っているのは、世界中のセキュリティコミュニティーという消火栓をシステムにつなぐことである。企業は負荷が掛かって少し大変な目に遭うだけだ。

　同じくサンフランシスコのバグ報奨金プログラムベンダー、米HackerOneでチーフポリシーオフィサーを務め、Microsoftのバグ報奨金プログラムの創始者でもあるケイティ・ムソウリ氏は次のように話している。「バグ報奨金プログラム開始後、報告されるバグ件数の多さだけではなく、そのバグの品質と重大度も量と同じくらい問題になる」

　HackerOneは、報奨金プログラムでバグを選別して提出範囲を制限するサービスを提供している。「金銭的な報酬がセキュリティ調査員から大きな関心を集める」とムソウリ氏は指摘する。すぐに修正しなければならない大量のバグが提出される状況に対応する準備ができていない企業には、プログラムの範囲を狭めるという選択肢がある。範囲を狭める方法は、報奨金の金額を下げるか、バグを提出できるセキュリティ調査員を制限するかのいずれかだ。

　「このような対策を講じる前に、企業はバグ報奨金プログラム実施のそもそもの理由を理解する必要がある」とムソウリ氏はいう。

　「プログラムの範囲を狭めることは、報告されるバグを管理するのに役立つ方法の1つとなるかもしれない。だが、当然ながら多くのセキュリティ脆弱性を見つけることには役立たない」（ムソウリ氏）

　ムソウリ氏によると、バグ報奨金プログラム支援企業のサービスを利用する企業の大半は、バグの選別についてのサポートを望んでいる。だが、多くの企業にとって必要なサポートが、もう1つある。それはバグの提出に関する決済インフラの確立だ。例えば、HackerOneでは、国際送金に関する管理、税金、規制、コンプライアンスの全てに対応しているとムソウリ氏はいう。

　GitHubがPayPal以外の支払い方法に対応していないことは、調査員の小さな不満の火種となっている。決済インフラはGitHubのバグ報奨金プログラムで改善が必要な数少ない分野の1つである。ムソウリ氏によると、これは多く見られる一般的な問題だという。

　同氏は過去を振り返って次のように話す。「Microsoftでは『Vulnerability Reward Program』を管理していた。世界中の調査員に対して報奨金を支払うためのインフラを準備するのは、Microsoftのような大企業でも容易ではなかった。企業がバグ報奨金プログラムの外部委託を検討するときには、決済インフラをその対象に含めた方がいい」

　米TechTargetが話を聞いた専門家は例外なくバグ報奨金プログラムを外部委託するメリットを強調した。だが、社内で対応するのが最善策となる企業もあるという指摘もあった。

　「Bugcrowdでアカウントがクローズされるのは、顧客が社内でプログラムを開始するか、バグ報奨金プログラム自体を取りやめるときだ」とエリス氏は話す。企業はそもそも、第三者が自社のコードに干渉することを好まない。そのため、報奨金プログラムにまつわるリスクが分かると、その実施をためらう。そのような場合、エリス氏は顧客企業に対して次のように提案している。「攻撃者はバグ報奨金プログラムを実施するかどうかに関係なくコードに干渉する。だが、ホワイトハッカーに適宜脆弱性を検出するよう働き掛けることは、悪意のある攻撃者がターゲットにできる欠陥の数を減らすことにつながる」

　バグ報奨金プログラムを外部委託することで、そのようなプログラムを実施するすべのない企業が、バグ報奨金プログラムを実施する機会が開けるだろう。「これは業界の素晴らしいトレンドだ。セキュリティ調査員に動機を与えることに注力し、継続的なセキュリティの評価サイクルを作成することで、どの企業もセキュリティの評価サイクルからメリットを得ることができる」とダベンポート氏は話す。