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

Organization 内の個々のリポジトリまたはすべてのリポジトリに対して secret scanning を有効にすることができます。 詳しい情� �については、「リポジトリのセキュリティと分析設定を管理する」または「Organization のセキュリティと分析設定を管理する」を参照してく� さい。

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

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

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

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

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

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

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

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

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

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

新しく公開されたシークレットを監視、通知、修復するプロセスを確立したら、GitHub Advanced Security が導入される前にコミットされたシークレットの作業を開始できます。

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

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

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

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

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

   この情� �を収集するには、セキュリティの概要を使用できます。 セキュリティの概要の使用に関する詳しい情� �については、「セキュリティの概要でのアラートのフィルタリング」を参照してく� さい。

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

   • Organization
   • リポジトリ
   • シークレットの種類
   • シークレット値
   • 連絡先のリポジトリの保守管理者

   注: その種類の漏洩したシークレットが少ない� �合は、UI を使用します。 数百ものシークレットが漏洩した� �合は、API を使用して情� �を収集します。 詳しい情� �については、「secret scanning REST API」を参照してく� さい。

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

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

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

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

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