小規模で始める
これは前にも触れましたが、もう一度確認する価値はあります。プログラムを世界に向けて発表して「公開」したくなるかもしれませんが、社内プログラムの場合は、プログラム ポリシーと報告書提出フォームを一般公開してしまいたくなるかもしれません。小規模から始めてスケールアップする機会が得られないため、リスクが発生する可能性があります。どんなに準備していても、VDP の立ち上げ時には必ず驚くことが起きます。想定よりも多くの脆弱性を受け取り、対応できない可能性があります。チームの半分が病気になり、バグのトリアージを助けられなくなることもあります。おそらく、認証スキャンの実行を試行し忘れ、研究者がそれをすると、100,000 の新規アカウントが作成され、誤ってシステムにフラッディングが生じてしまいます。どんなことがあっても、小規模で始めて、時間をかけてプログラムを徐々に拡大していくことをおすすめします。問題が発生しますが、これはまったく普通のことですが、これらの問題を 1 つずつ処理するための帯域幅を確保することをおすすめします。
プログラムを自社で構築する場合でも、プログラム ポリシーを策定し、ウェブサイトで報告フォームを提出することをおすすめします。ただし、閲覧できるようにハッカーのログインを必須にすることもできます。サードパーティのプラットフォームを使用している場合は、少数のセキュリティ研究者の招待が自動的に処理されます。いずれの場合も、非公開の VDP にハッカーを招待する際に使用する招待テンプレートを以下のように作成します。
お客様 <組織名> 様から、限定公開の VDP への参加についてご案内いたします。最初は限定公開モードで小規模に開始し、VDP プロセスに基づいてセキュリティ研究者に最高のエクスペリエンスを提供できるようにしています。テストのガイドラインと範囲については、プログラム ポリシーをご覧ください。VDP の初期段階でフィードバックがございましたら、ぜひお知らせください。最初の研究者セットを招待してプログラムへのアクセス権が付与されると、レポートの送信が開始されます。あるいは、レポートがまったく届かなくても問題ありません。5 人のセキュリティ研究者を招待するとします。2 人がビジー状態で、プログラムをまったく確認しない可能性もあります。もう 1 人は休暇中で、招待メッセージをまったく受け取っていない可能性があります。4 人目と 5 人目のハッカーは調査を行い、1 ～ 2 日ほどテストを行いますが、脆弱性を見つけることはありません。数週間後に戻ってきて何か報告したかもしれませんが、この作業をすべてこなして招待状を送信し、レポートがまったく届かないというのは、まだ衝撃的なことです。その場合は、これはまったく普通のことであり、小規模から始めて規模を拡大する理由です。5 回送信してもレポートの量がそれほど多くない場合は、さらに 5 回、さらに 5 回、10 回、または 20 回送信します。サードパーティのプラットフォームを使用している場合は、希望するレポートの量に応じて徐々にハッカーを招待する自動メカニズムがあります。一方、セキュリティ研究者を 5 人招待しただけで大量の脆弱性レポートを受け取った場合は、レポートの量が落ち着くまで招待を保留するとよいでしょう。
トリアージと反復
VDP を開始してから 1 ～ 2 週間は、受信した脆弱性レポートの選別、バグの報告、研究者との連絡を、2 人以上の担当者に同時に担当させることをおすすめします。通常、プログラムのリリース時にレポートが急増し、その後は落ち着きます。送られてきた脆弱性レポートを選別する際に、ハッカーからのフィードバックを受け、プログラム ポリシーのギャップや誤解が特定されることがあります。プロセスやツールに問題が見つかる場合もあります。小規模で始めて、最初の数週間はチームが多くの注意を払ってエネルギーを注ぐので、この時間を利用してプログラムを迅速にイテレーションして改善してください。1 ～ 2 か月後には機能しなくなり、プログラムをスムーズに実行することは当たり前になります。
スケールアップ、一般公開
チームがプログラムの実行に慣れてきたら、ますます多くのハッカーを招待してきます。対象範囲が拡大され、知っている情報（さらには存在に気付かなかったアセットも含む）も含まれるようになりました。最終的には 100 人、ときには数百人のハッカーを招待することもありますが、レポートの量は減少しているように見えます。送信されるレポートの重大度は、すべて低または中程度のようです。勤務中のローテーションはかなり簡単なようで、チームは脆弱性レポートの優先順位付け、解決の推進、ハッカーとの連絡について熟知しています。この時点で、プログラムを公開する準備は完了しています。公開する前に、すべての関係者と再度連絡を取り、公開リリースを認識して承認していることを確認します。最初の限定公開リリースと同様に、一般公開のリリースでも報告量が急増する可能性に備えます。一般公開でのリリースの主な違いの一つは、脆弱性レポートは誰でも提出できるという点です。ただし、この方法では、大量のノイズが発生する可能性があります。たとえば、アカウントへのログイン方法がわからなかったり、フォームに入力したりメールを送信したりするスパムボットが、VDP にレポートを送信する可能性があります。セキュリティに関連しない一般的なレポートを素早く閉じたり、フォームを調整してユーザーを適切な場所（たとえば、パスワードを忘れたなどのサポート スタッフ）にリダイレクトすることで、テンプレートを用意しておくと便利です。明るいニュースは、以前は連絡が取れなかった熟練のハッカーに、プログラムを公開することで、以前は連絡が取れなかった熟練したハッカーに、対応できるようになります。これにより、重大度が「高」または「重大」の脆弱性を発見できる可能性があります。また、このガイドの前半で説明したすべての利点も備えています。たとえば、グローバルなハッキング コミュニティ向けの標準化されたチャネルで脆弱性をユーザーに直接開示することで、侵害のリスクや否定的な PR を低減できます。
祝う
長い道のりを歩んできたことで、VDP が公開されました。貴社のチームと、これまでサポートしていただいたすべての関係者とお祝いすることを忘れないでください。大切なのは感謝の気持ちを示し、一緒に成功を称える方法を見つけることです。VDP の公式リリースを祝うだけでなく、リリースの記念日などのマイルストーンの達成も忘れないでください。VDP を通じて発見され修正された特に興味深い重大なバグを強調します。途中で指標を収集することで、プログラムの成功を示し、自分とチームの成果を強調できます。