最初のキャンペーンの開始
このチュートリアルでは、XSS アラートに焦点を当てた組織全体の最初のセキュリティ キャンペーンを計画し、実行します。 その過程で、適切なアラートを選択し、開発者が成功できるように準備し、セキュリティ体制の有意な改善を促進するキャンペーンを構築する方法について説明します。
複数のリポジトリで XSS の脆弱性の繰り返しパターンを特定したとします。 アラートに 1 つずつ対処するのではなく、開発者が安全なコーディングに自信を持てるよう、リスクを軽減する調整されたキャンペーンを実行することにします。
1. 重点的な目標を定義する
大規模なキャンペーンを実行する場合は、緊急のアラートをすべて一度に対象にしたくなる可能性があります。 開発者がセキュリティで保護されたコーディングと使用可能な容量に関する強力な基盤を既に持っている場合は、それが機能する可能性があります。
ただし、リスクを軽減し、セキュリティで保護されたコーディングプラクティスを改善することが目標である場合は、多くの場合、焦点を絞ったキャンペーンの方が効果的です。 クロスサイト スクリプティングなど、1 つの脆弱性の種類を選択すると、開発者はパターンを認識し、複数の修正プログラムに学習を適用し、勢いを構築できます。
このキャンペーンでは、1 つのキャンペーンに含めることができるアラートの数の制限内で、組織全体の XSS アラートに重点を置きます。
2. キャンペーンのアラートを選択する
[セキュリティ アラート] ページで、クロスサイト スクリプティング アラートをフィルター処理することから始めます。 クロスサイト スクリプティング (CWE-79) などの定義済みのキャンペーン テンプレートを使用して、スコープをすばやく定義することもできます。 アラートのフィルター処理については、 セキュリティの概要でアラートをフィルター処理する を参照してください。
メモ
セキュリティ キャンペーンには、最大 1,000 件のアラートを含めることができます。 組織に 1,000 を超える XSS アラートがある場合は、一致するアラートの数がこの制限内になるまでフィルター (リポジトリ、重大度、言語など) を絞り込むか、残りのアラートに対応するように複数のキャンペーンを計画します。
お客様に該当するキャンペーンで Copilotの自動修正 が使用可能な場合は、autofix:supported フィルターを使用して範囲をさらに絞り込むことができます。 これにより、開発者は AI によって生成された修正候補を利用して、アラートをより効率的に修復できます。
キャンペーンを開始する前に、サポートとなる教育資料を準備します。 例えば次が挙げられます。
- XSS の脆弱性の防止に関するガイダンスを含むリポジトリを作成します。
-
[クロス サイト スクリプティング (XSS](https://owasp.org/www-community/attacks/xss/)) など、OWASP Foundation のリソースへのリンク。 - セキュリティで保護されたコーディング パターンとテスト 方法の例を示します。
これらのリソースへのリンクをキャンペーンの説明に含め、開発者が割り当てられたアラートを操作するときに参照できるようにします。
3. キャンペーン マネージャーを割り当て、コミュニケーション チャネルを定義する
キャンペーンを開始する前に、修復プロセス全体を通じて開発者をサポートするユーザーを決定します。
セキュリティ キャンペーンを作成するときは、1 人以上の キャンペーン マネージャーを割り当てる必要があります。 キャンペーン マネージャーは次の必要があります。
- 組織の所有者ロールまたはセキュリティ マネージャー ロールを持つユーザー、または
- これらのロールの 1 つを持つチームのメンバー
次のことができるマネージャーを選びます。
- XSS の脆弱性に関する質問に回答する
- 修正のためのプルリクエストを確認する
- エッジ ケースまたは複雑な修復シナリオの解決に役立つ
キャンペーン マネージャーはキャンペーンに参加している開発者に表示されるため、これは明確なコミュニケーションを確立する機会でもあります。 キャンペーンを作成するときは、GitHub Discussions スレッドまたは別のコミュニケーション チャネルへのリンクなどの連絡先リンクを含めて、開発者が質問する場所を把握します。
早期に期待を設定し、サポートを表示することで、信頼を高め、修復率を向上させることができます。
4. キャンペーンを作成して公開する
これで、キャンペーンを作成する準備ができました。
キャンペーンを定義する場合:
- XSS フィルターまたはテンプレートを使用してアラートを選択します。
- キャンペーンの目標を説明する明確な説明を追加します。
- 前に準備した教育リソースへのリンクを含めます。
- アラートの数と予想される修復容量に基づいて、現実的な期限を設定します。
範囲がわからない場合は、まず 下書きキャンペーン を作成します。 下書きを使用すると、公開する前に含まれるアラートを確認し、内部で共同作業を行うことができます。
5. 問題の追跡を有効にして可視性を高める
開発者が自分の作業を追跡し、マネージャーに可視性を提供できるように、キャンペーンに含まれる各リポジトリに問題を自動的に作成することを選択できます。 これにより、開発者は既存のワークフローとプロジェクト ボード内で修復作業を管理できます。
問題の作成を有効にすると、キャンペーンの "短い説明"、"連絡先リンク"、期限が自動的に問題の本文に含まれます。 短い説明、連絡先リンク、または期限を更新すると、それらの変更が問題に反映されます。 さらに、キャンペーンが期限に達するか、または終了すると、各問題にコメントが投稿され、開発者に通知されます。 この統合は、明確なコミュニケーションを維持し、複数のリポジトリ間でキャンペーンを整理し続けるのに役立ちます。
6. 修復中に開発者をサポートする
キャンペーンが有効になると、ロールはオーガナイザーからイネーブラーに移行します。 開発者は、リポジトリ内の XSS アラートの確認と修正を開始します。 効率的かつ自信を持って移動できるように、次の手順を実行します。
- キャンペーン マネージャーが pull request を確認し、質問に回答できることを確認します。
- 開発者がコードの脆弱性と修正の検証方法をより理解するために、Copilot チャット を利用することを推奨します。
- サポートされている場合は、変更をマージする前に、開発者が Copilotの自動修正 の提案を確認してテストすることをお勧めします。
前に教育リソースを準備した場合は、ディスカッションやプルリクエストのレビューで参照してください。 共有ガイダンスを強化すると、繰り返し寄せられる質問が減り、長期的に安全なコーディング習慣を構築できます。
キャンペーン中に目に見え、応答性を維持することで、これはコンプライアンスの演習だけでなく、共同作業であることを強化します。
7. 現実的な期限を設定する
キャンペーンの作成時に期限を設定します。 キャンペーンが進行するにつれて、タイムラインが達成可能なままであることを確認します。
期限を設定または調整する場合は、次のことを検討してください。
- キャンペーンに含まれるアラートの数
- 開発者の予想される修復容量 (たとえば、通常の作業と共にアラートの修正にどの程度の時間を使うことができるか)
- 今後の会社の期限または休日が、可用性に影響を与える可能性がある場合
アラートの修復が専用のイニシアチブでない限り、ほとんどの開発者はこの作業と機能開発のバランスを取ります。 現実的なタイムラインを設定すると、参加が増え、落胆を防ぐことができます。
必要に応じて、一度にすべての種類のアラートに対処するのではなく、時間の経過と同時に複数の集中キャンペーンを実行できます。
8. キャンペーンを閉じて反復する
期限が近づくにつれて、進行状況を監視し、残りの複雑な修正プログラムで共同作業を行います。
キャンペーンが終了した場合:
- リポジトリの問題は自動的に更新されます。
- 開発者は、焦点を絞った一連の脆弱性を解決しました。
- 組織は、測定可能な方法でリスクを軽減しました。
最も重要なのは、開発者が特定のクラスの脆弱性を認識して修正する実践的な経験を積んだことです。
ここから、SQL インジェクション、安全でない逆シリアル化、公開されたシークレットなど、別の対象のアラート セットでプロセスを繰り返して、時間の経過と共に組織のセキュリティ体制を着実に向上させることができます。
次のステップ
キャンペーンを開始する準備はできましたか? セキュリティ キャンペーンを作成して管理するには、 セキュリティ キャンペーンの作成と管理 を参照してください。