フェーズ 6: secret scanning のロールアウトとスケーリング

組織または企業内の個々のリポジトリまたはすべてのリポジトリに対し、シークレット スキャンを有効にすることができます。 詳細については、「リポジトリのセキュリティと分析設定を管理する」、「組織のセキュリティおよび分析設定を管理する」、または「Enterprise 用の GitHub Advanced Security 機能の管理」を参照してください。

この記事では、Organization 内のすべてのリポジトリに対する secret scanning の有効化に重点を置いてプロセスの概要について説明します。 この記事で説明する原則は、時間をずらして、個々のリポジトリに対して secret scanning を有効にする場合でも適用できます。

1. 新しくコミットされたシークレットに集中する

secret scanning を有効にする場合、secret scanning によって検出された、新しくコミットされた資格情報の修復に集中する必要があります。 コミットされた資格情報のクリーンアップに集中すると、開発者は誤って新しい視覚情報をプッシュし続ける可能性があります。つまり、シークレットの合計数は、意図したとおりに減少せず、ほぼ同じレベルにとどまります。 現在のシークレットを取り消すことに集中する前に、新しい資格情報が漏洩するのを止めることが不可欠なのは、このためです。

新しくコミットされた資格情報に取り組むためのアプローチはいくつかありますが、その一例は次のとおりです。

1. 通知: Webhook を使用して、新しいシークレット アラートが、可能な限り迅速に適切なチームに表示されるようにします。 Webhook は、シークレット アラートが作成または解決されるか、もう一度開かれたときに発生します。 その後、Webhook ペイロードを解析し、Slack、Teams、Splunk、メールなど、自分やチームが使用するツールと統合できます。 詳細については、「webhook について」および「Webhook のイベントとペイロード」を参照してください。

2. フォローアップ: すべてのシークレットの種類に対して機能する高度な修復プロセスを作成します。 たとえば、シークレットをコミットした開発者とそのプロジェクトの技術リーダーに連絡し、シークレットを GitHub にコミットする危険性を強調し、検出されたシークレットの取り消しと更新を依頼することができます。

   Note

   このステップは自動化できます。 数百のリポジトリを持つ大規模な Enterprise および Organization の場合、手動によるフォローアップを持続するのは不可能です。 最初の手順で定義した Webhook プロセスに自動化を取り入れることができます。 Webhook ペイロードには、漏洩したシークレットに関するリポジトリおよび Organization 情報が含まれます。 この情報を使って、リポジトリの現在のメンテナンス担当者に連絡し、責任者宛のメールやメッセージを作成したり、issue を開いたりすることができます。

3. 教育: シークレットをコミットした開発者に割り当てる内部トレーニング ドキュメントを作成します。 このトレーニング ドキュメントでは、シークレットをコミットすることによって生じるリスクを説明し、開発中のシークレットの安全な使用についてベスト プラクティス情報を指示します。 開発者が経験から学ばず、シークレットのコミットを続ける場合、エスカレーション プロセスを作成できますが、通常は教育する方が効果的です。

漏洩した新しいシークレットについて最後の 2 つの手順を繰り返します。 このプロセスにより、開発者はコードで使用されるシークレットを安全に管理することに対して責任を負うようになり、新しくコミットされたシークレットの削減を測定できます。

2. プッシュ保護を有効にする

secret scanning を有効にしたら、プッシュ保護も有効にする必要があります。 プッシュ保護を使用すると、secret scanning チェックはサポートされているシークレットをプッシュし、シークレットが他のユーザーに公開される_前に_ GitHub へのプッシュをブロックします。 プッシュ保護を有効にする方法の詳細については、「リポジトリのプッシュ保護の有効化」を参照してください。

有効にすると、次の操作を実行できます。

1. ガイダンスを提供する: secret scanning によってプッシュがブロックされているかどうかを共同作成者が確認するメッセージにカスタム リンクを構成します。 リンクされたリソースは、ブロックされたプッシュを解決する方法に関する共同作成者向けのガイダンスを提供できます。 詳しくは、「リポジトリのプッシュ保護の有効化」をご覧ください。

2. 通知: アラート プロパティ "push_protection_bypassed": true を使用してプッシュ保護をバイパスしたときに作成された シークレット スキャンニング アラート を具体的に追跡する Webhook を定義します。 または、API を使用して、シークレット スキャンニング アラート がプッシュ保護バイパスの結果であった更新を取得するために、"push_protection_bypassed": true の結果の一覧をフィルター処理します。 詳しくは、「セキュリティ アラートの監査」をご覧ください。

3. 以前にコミットされたシークレットを最も重要なものから順に修復する

コードベースへのシークレットの追加を減らすプロセスを確立したら、GitHub Advanced Security を導入する前にコミットされたシークレットの修復作業を開始する準備ができました。

最も重要なシークレットを定義する方法は、Organization のプロセスと統合によって異なります。 たとえば、企業は Slack を使用していない場合、Slack Incoming Webhook のシークレットについて心配しない可能性があります。 Organization にとって最も重要な資格情報の種類の上位 5 つに注目することから始めると便利な場合があります。

シークレットの種類を決定したら、次の手順を実行できます。

1. 各種類のシークレットを修復するためのプロセスを定義します。 多くの場合、実際の手順は、シークレットの種類によって大きく異なります。 ドキュメントまたは内部のナレッジ ベースに、シークレットの種類ごとのプロセスを書き留めます。

   Note

   シークレットを取り消すプロセスを策定する場合は、中央のチームではなく、リポジトリを保守しているチームにシークレットを取り消す責任を与えます。 GHAS の原則の 1 つは、特に、開発者がセキュリティ イシューを作成した場合、開発者がセキュリティの所有権を取得し、セキュリティ イシューを修正する責任を担うことです。

2. 資格情報を取り消すためにチームが従うプロセスを作成したら、シークレットの種類と、漏洩したシークレットに関連付けられているその他のメタデータに関する情報を照合して、新しいプロセスの伝達先を識別することができます。

   この情報を収集するには、セキュリティの概要を使用できます。 セキュリティの概要の使用方法の詳細については、「セキュリティの概要でアラートをフィルター処理する」を参照してください。

   収集する必要がある情報としては、次のものがあります。

   • Organization

   • リポジトリ

   • シークレットの種類

   • シークレット値

   • 連絡先のリポジトリの保守管理者

   Note

   その種類の漏洩したシークレットが少ない場合は、UI を使用します。 数百ものシークレットが漏洩した場合は、API を使用して情報を収集します。 詳しくは、「シークレット スキャン用の REST API エンドポイント」をご覧ください。

3. 漏洩したシークレットに関する情報を収集したら、シークレットの各種類によって影響を受けるリポジトリを保守しているユーザーを対象とした通信計画を作成します。 電子メールまたはメッセージングを使用でき、影響を受けるリポジトリに GitHub イシューを作成することもできます。 これらのツールによって提供される API を使用して自動的に連絡を送信できる場合、これにより、複数のシークレットの種類にまたがって簡単にスケーリングできます。

4. プログラムを拡張してより多くのシークレットの種類とカスタム パターンを含める

これで、5 つの最も重要なシークレットの種類を超えて、教育にさらに焦点を当てた、より包括的なリストに拡張できます。 対象としたさまざまなシークレットの種類について前の手順を繰り返し、以前にコミットされたシークレットを修正できます。

また、初期のフェーズで照合されたより多くのカスタム パターンを含めて、さらに多くのパターンを送信するようにセキュリティ チームや開発者チームに促し、新しいシークレットの種類タイプが作成されたときに新しいパターンを送信するプロセスを確立することもできます。 詳しくは、「シークレット スキャンのカスタム パターンの定義」をご覧ください。

他のシークレットの種類の修復プロセスを引き続き構築する際は、組織内の GitHub のすべての開発者と共有できるプロアクティブなトレーニング資料の作成を開始します。 この時点まで、焦点の多くはリアクティブでした。 焦点をプロアクティブに変えて、まず、開発者が GitHub に資格情報をプッシュしないように促すことは、優れたアイデアです。 これは複数の方法で実現できますが、リスクと理由を説明する短いドキュメントを作成することが出発点として適しています。