よって翻訳されました。必要に応じて、コンテンツの保存と分類を行います。不可欠であり、慎重に作成する必要があります。参加する際に最初に目にするものです。プログラムのトーンや期待値、参加を選択する研究者に対するコミットメントを定めます。ポリシーの下書きを作成します。ページのみで、通常は次のトピックが含まれます。ポリシーは、研究者になる可能性があるすべての人が利用できるようにする必要があります。利用できるようにするなんらかのアクセス制御が必要です。エイリアスなど、レポートを送信する方法も必要です。リソースを設定する際は、この点を考慮してください。サードパーティの脆弱性開示とバグ発見報奨金プラットフォームには、一般に次のような機能があります。サービスも用意されています。サービスには費用がかかります。サードパーティを利用する場合と、プログラムを社内で構築、管理する場合を比較して、費用とメリットを比較して、最適な方法を判断してください。Systems」をご覧ください。ポリシーの草案を作成する際には、ステークホルダーとの連携方法を検討してください。ポリシーと利用規約の草案を作成します。研究者に報酬は支払われないため、広範なオンボーディング要件や負担の大きい条件の対象にすべき理由はありません。チームと協力して、サービス拒否条件を設定しないなど、テストの要件とスコープを作成します。チームが、テストの要件や範囲(特に興味深い脆弱性、最も関心が低い脆弱性の種類など)について情報を提供してもらう場合があります。チームと協力して、開示に関するポリシーの文言を確認します。チームがポリシーの作成を主導します。チームはハッカーからのフィードバックを受け取り、他の関係者とともに時間をかけてポリシーのイテレーションを行います。ガイドラインに従って誠意をもって行動する、参加する研究者に対する組織のコミットメントについて説明します。レポートに対応するとともに、どの脆弱性レポートを受け入れて修正するかの判断を伝えるというコミットメント。システムとサービスの脆弱性の特定と修正に取り組みます。以下の事項の約束をするように最善を尽くします。営業日以内に脆弱性レポートへの最初の回答をお願いします。ポリシーにセーフハーバーの文言を導入すると、研究者が誠意を持って行動し、ポリシーに記載されているすべてのガイドラインに従う限り、システムに対するテストのために法的措置が取られることはなくなります。ポリシーの下書き時に使用できるセーフハーバー言語のテンプレートが用意されています。法務チームと連携してこの文言を評価し、ニーズに合わせて調整してください。テストと、対象範囲外であり研究者による回避が必要なテストが記載されています。研究者が注目してほしい特定の種類の脆弱性がある場合は、このセクションでそれを強調することをおすすめします。テストを実施する際は、次のガイドラインを遵守してください。アカウントを作成する)。までお知らせください。そのようなユーザーデータは保存しないでください。サービス拒否状態や本番環境サービスの低下につながるテストは実行しないでください。エンジニアリングは、このプログラムの対象外です。エンジニアリングは行わないでください。次の種類の脆弱性と影響に関心があります。次のような脆弱性は、誤検出や許容されるリスクとして拒否される可能性が高いため、あまり重要ではありません。一部と見なされないアセットを定義します。スコープは慎重に検討し、チームに過負荷にならないように可能な限り拡大する必要があります。対象範囲に回答する意欲が高いほど、セキュリティ研究者から関与する可能性が高くなります。チームが受信レポートに対応できなくなるほど、スコープを広範囲にしないでください。スコープ内のアセットをいくつか検討します。受け取るレポートの量がよくわかるように、範囲を広げます。一般公開する前に、すべての項目を対象範囲に含めてください。ポリシー内でスコープを定義する方法に関しては、各アセットまたは領域の詳細を追加することで、セキュリティ研究者はあなたにとって何が重要で、どこに重点を置くべきかを理解しやすくなります。アセットを安全にテストする方法に関するヒントを含めることもできます。次の例をご覧ください。他のユーザーのメールへの不正アクセスを引き起こす脆弱性。別のユーザーのメールアドレスまたはアカウント全体を回復不能な方法で削除する機能。悪質な可能性のある添付ファイルの送信機能テストのガイドラインテストは、ご自身が所有するアカウント、またはテストに対する明示的な同意があるアカウントでのみ実施してください。アカウントを作成する場合は、ユーザー名のどこかに「vdptest」を含めます。これはかなり詳細な内訳です。対象範囲内のアセットと対象範囲外のアセットの簡単なリストを含めることもできます。開始する前に、特定のリソースを用意する必要があります。次のリソースが必要になります。開始スケジュールに合わせて調整するとともに、開始に必要なリソースをキューに入れます。バグが大量に処理されることにチームが備えられるようにすることをおすすめします。リリース日を認識し、テスト開始時により多くの時間とリソースを割り当てることを検討します。日常業務をサポートするチームを作る必要もあります。実行するには、割り込みベースの運用作業が相当量必要です。行い、バグをすべて報告し、ステータスを追跡し、最新情報を研究者に伝えると、すべて自分で作業ミスをするかもしれません。運用と実行を支援するチームの構築を手伝ってもらいましょう。成功に責任を負う、定義された「オーナー」または「リーダー」が必要ですが、そのリーダーをサポートするチームも必要です。サポートに前向きになったら、勤務スケジュールを設定してその体制を整えます。これは任意の方法で作成できますが、毎週ローテーションするのが一般的な方法です。その週の勤務中は、次のことを行ってください。受信した脆弱性レポートを確認します。既存の脆弱性をプッシュフォワードします。過去勤務週に報告されたバグを確認し、重大度基準と修復タイムラインに基づいて修復が進行していることを確認します。オーナーを見つけることのヒントを参考に、オーナーにこれらのバグに対処するよう説得してください。既存のレポートに関する最新情報をセキュリティ研究者に提供します。研究者は既存のレポートの更新を積極的に要求する場合があります。これを確認し、必要に応じて対応します。脆弱性が修正された場合は、研究者にその旨を伝え、彼らの努力が組織にポジティブな変化をもたらしたことを伝えます。修正に漏れがないかどうかや、修正がなんらかの方法で回避される可能性があるかどうかを研究者に依頼するテンプレート言語を含めることもできます。週間かかることもあります。ローテーションを成功させるためのヒントは次のとおりです。重い週には出勤をサポートできるように、チームの準備を整えます。適切な引き継ぎプロセスを用意します。次の担当者が直ちに対応しなければならない問題がある場合は、引き継ぎのメモを作成するか、週末にリアルタイムで会話します。自動スケジュールを作成すると、全員が自分の勤務時間を把握できます。エントリを作成するのと同じくらい簡単です。開始前には、担当する人物が週を思い出し、サポートが必要かどうかを再確認します。ローテーションに参加する経験の浅いリソースが多い場合は、より多くの上級リソースが連携して、従業員が安心して参加できるようにし、立ち上げ時に質問できるようにします。週単位で入れ替える柔軟なプロセスを用意する。週間の間に休暇を取ったり、誰かが有給休暇を取得したりすることになるでしょう。そのような場合は、全員のスケジュールに合わせて、必要に応じて週を入れ替えるようチームに促します。リファレンス」を作成します。構築して実行することに基づいています。サービスやプラットフォームを利用できます。作成、リリース、実施する方法についてのガイダンスとして役立ちます。サービスを提供していることもあります。このプロセスを社内で構築するか、サードパーティのプラットフォームを使用するかは、要件と利用可能なリソースによって決まります。予算が多くても人員が少ない場合は、プログラムの実行にサードパーティを利用することが合理的です。ない場合は、時間をかけてプログラムを自作する価値があるかもしれません。レポートの受信サードパーティのプラットフォームを使用する場合は、ハッカーがユーザーに直接報告を送信する手段を用意する必要があります。ポリシーと同じページからリンクまたは同じページからリンクされている必須のフォーム項目を含むウェブフォームである場合もあります。どのような形式であれ、レポートを受け取りたい形式をハッカーに伝えるために、チャンスを逃さないようにしましょう。ハッカーに対して、特定の形式でレポートを送信するよう依頼すれば、必ず報告できるとは限りませんが、報告しても問題はありません。レポート送信フォームでリクエストする内容の例を次に示します。行で説明してください。[脆弱性の簡単な説明と、その脆弱性が重要な理由を追加してください。これにより、攻撃者は被害者のアカウントにログインできます。[脆弱性を再現する手順を追加してください。[必要に応じて、この問題の修正方法に関するアドバイスがあれば、ここに追加します。ライセンスに記載のライセンスに従います。関連会社の商標または登録商標です。