フェーズ 2: 大規模な有効化の準備

この記事は、GitHub Advanced Security の大規模な導入に関するシリーズの一部です。このシリーズの前の記事については「フェーズ 1: ロールアウト戦略と目標に合わせる」を参照してください。

code scanning の有効化の準備

Code scanning は、GitHub リポジトリ内のコードを分析して、セキュリティの脆弱性とコーディングエラーを見つけることができる機能です。分析によって特定された問題は、リポジトリに表示されます。詳しくは「コードスキャンについて」をご覧ください。

数百のリポジトリに code scanning をロールアウトすることは、特に非効率に行われる場合、困難なことがあります。これらの手順に従うと、ロールアウトが効率的で成功することが保証されます。準備の一環として、チームと連携し、自動化を使用してリポジトリに関するデータを収集し、code scanning を有効にします。

code scanning のためのチームの準備

最初に、code scanning を使用するためのチームの準備を行います。 code scanning を使用するチームが多いほど、修復計画を推進してロールアウトの進行状況を監視するために必要なデータが増えます。このフェーズでは、API の活用と内部有効化イベントの実行を重点的に取り上げます。

主な目的として、できるかぎり多くのチームが code scanning を使用できるように準備する必要があります。修復を適切に行うことをチームに促すこともできますが、このフェーズでは、イシューの修復よりも code scanning の有効化と使用を優先することをお勧めします。

リポジトリに関する情報の収集

GitHub Enterprise Server の GraphQL API を使用すると、リポジトリで使用されているさまざまなプログラミング言語に関する情報をプログラムで収集し、そのデータを使用して、同じ言語を使用するすべてのリポジトリで code scanning を有効にすることができます。

注: この記事で説明する GraphQL クエリを手動で実行せずにこのデータを収集するには、一般公開されているツールを使用できます。詳しい情報については、"ghas-enablement ツール" リポジトリを参照してください。

エンタープライズ内の複数の組織に属するリポジトリから情報を収集する必要がある場合、次のクエリを使用して、組織の名前を取得し、それをリポジトリクエリにフィードすることができます。 OCTO-エンタープライズを自身のエンタープライズ名に置き換えます。

query {
  enterprise(slug: "OCTO-ENTERPRISE") {
    organizations(first: 100) {
      totalCount
      nodes {
        name
      }
      pageInfo {
        endCursor
        hasNextPage
      }
    }
  }
}

組織レベルで言語別にリポジトリを照合すると、どのリポジトリでどの言語が使用されているかを識別できます。次のサンプル GraphQL クエリは、OCTO-ORG を組織名に置き換えて変更することができます。

query {
  organization(login: "OCTO-ORG") {
    repositories(first: 100) {
      totalCount
      nodes {
        nameWithOwner
        languages(first: 100) {
          totalCount
          nodes {
            name
          }
        }
      }
      pageInfo {
        endCursor
        hasNextPage
      }
    }
  }
}

GraphQL クエリの実行に関する詳しい情報については、「GraphQLでの呼び出しの作成」を参照してください。

次に、データを GraphQL クエリから、テーブルなどの読み取り可能な形式に変換します。

言語	リポジトリの数	リポジトリ名
JavaScript (TypeScript)	4212	org/repo org/repo
Python	2012	org/repo org/repo
Go	983	org/repo org/repo
Java	412	org/repo org/repo
Swift	111	org/repo org/repo
Kotlin	82	org/repo org/repo
C	12	org/repo org/repo

GitHub Advanced Security で現在サポートされていない言語をこのテーブルから除外できます。

複数の言語を使用するリポジトリがある場合は、次の表示に示すように、GraphQL 結果を書式設定できます。サポートされていない言語を除外しますが、少なくとも 1 つのサポートされている言語を使用するリポジトリはすべて保持します。これらのリポジトリで code scanning を有効にすることができ、サポートされているすべての言語がスキャンされます。

言語	リポジトリの数	リポジトリ名
JavaScript/Python/Go	16	org/repo org/repo
Rust/TypeScript/Python	12	org/repo org/repo

どのリポジトリでどの言語が使用されているかを把握すると、フェーズ 3 でパイロットプログラムの候補リポジトリを識別し、フェーズ 5 で、すべてのリポジトリで一度に 1 つの言語に対して code scanning を有効にするための準備を行うのに役立ちます。

アプライアンスに対する code scanning の有効化

パイロットプログラムと、エンタープライズ全体での code scanning の有効化に進む前に、まず、アプライアンスに対して code scanning を有効にする必要があります。詳しくは、「アプライアンス用コードスキャンの構成」を参照してください。

secret scanning を有効にするための準備

注: secret scanning を有効にしたリポジトリでシークレットが検出されると、GitHub はリポジトリのセキュリティアラートにアクセスできるすべてのユーザーに警告します。

プロジェクトで外部サービスと通信する場合、認証にトークンまたは秘密キーを使用できます。リポジトリにシークレットをチェックインする場合、リポジトリへの読み取りアクセスを持つすべてのユーザがシークレットを使用して、自分の権限で外部サービスにアクセスできます。 Secret scanning では、GitHub リポジトリ内に存在するすべてのブランチで Git 履歴全体をスキャンしてシークレットを確認し、プッシュにシークレットが含まれていることを警告するか、そのプッシュをブロックします。詳しくは、「シークレットスキャンについて」を参照してください。

secret scanning を有効にする際の考慮事項

GitHub Enterprise Server の secret scanning 機能は、プログラミング言語ごと、またはリポジトリごとに個別の構成を必要とせず、全体的に少ない構成で開始できるため、code scanning とは多少異なります。つまり、組織レベルで secret scanning を有効にするのは簡単ですが、組織レベルで [すべて有効にする ] をクリックし、 [新しいリポジトリごとに secret scanning を自動的に有効にする] オプションをオンにすると、明らかなダウンストリーム効果が得られます。

ライセンスの消費

すべてのリポジトリで secret scanning を有効にすると、GitHub Advanced Security ライセンスの使用が最大化されます。これは、すべてのリポジトリに対する現在のコミッターに十分なライセンスがある場合、問題にはなりません。アクティブな開発者の数が今後数か月間に増加する可能性がある場合は、ライセンス制限を超え、新しく作成されたリポジトリで GitHub Advanced Security を使用できなくなる可能性があります。

最初に大量のシークレットが検出される可能性がある

大規模な組織で secret scanning を有効にする場合、多数のシークレットが検出されたときに備えて準備を行う必要があります。場合によっては、これは組織に衝撃を与え、警告が発生します。一度にすべてのリポジトリで secret scanning を有効にする場合は、組織全体での複数のアラートに対応する方法を計画します。

Secret scanning は、個々のリポジトリに対して有効にすることができます。詳しくは、「リポジトリのシークレットスキャンの構成」を参照してください。また、前述のとおり、Secret scanning は、組織内のすべてのリポジトリに対して有効にすることもできます。すべてのリポジトリの有効化の詳細については、「組織のセキュリティおよび分析設定を管理する」を参照してください。

secret scanning のカスタムパターン

Secret scanning では、多数の既定のパターンが検出されますが、インフラストラクチャ固有のシークレット形式や、GitHub Enterprise Server の secret scanning では現在検出されないがインテグレーターによって使用されるシークレット形式などのカスタムパターンを検出するように構成することもできます。パートナーパターンでサポートされるシークレットの詳細については、「secret scanning パターン」を参照してください。

リポジトリを監査し、セキュリティチームおよび開発者チームに説明する際には、後で secret scanning のカスタムパターンを構成するために使用するシークレットの種類の一覧を作成します。詳しくは、「シークレットスキャンのカスタムパターンの定義」を参照してください。

secret scanningのプッシュ保護

組織とリポジトリのプッシュ保護は、シークレットがコードベースにコミットされる_前に_、サポートされているシークレットのプッシュをチェックするように secret scanning に指示します。サポートされているシークレットの詳細については、「secret scanning パターン」を参照してください。

プッシュでシークレットが検出された場合、そのプッシュはブロックされます。 Secret scanning には、作成者がシークレットを確認して削除できるように、検出したシークレットが一覧表示されます。また、必要に応じて、それらのシークレットをプッシュできるようにします。

開発者は、シークレットが誤検知であるか、テストで使用されているか、後で修正されることを報告することにより、プッシュ保護をバイパスするオプションがあります。

共同作成者がシークレットのプッシュ保護ブロックをバイパスする場合、GitHub では次のことが行われます。

リポジトリの [セキュリティ] タブでアラートを作成する。
バイパスイベントを監査ログに追加する。
リポジトリを監視している Organization または個人アカウントの所有者、セキュリティマネージャー、リポジトリ管理者に、シークレットへのリンクとそれが許可された理由を含むメールアラートを送信する。

プッシュ保護を有効にする前に、プッシュ保護をバイパスするための許容条件に関するガイダンスを開発者チームに作成する必要があるかどうかを検討してください。開発者がブロックされたシークレットをプッシュしようとしたときに表示されるメッセージで、このリソースへのリンクを構成できます。

次に、共同作成者がプッシュ保護をバイパスした結果であるアラートを管理および監視するためのさまざまなオプションについて理解します。

詳しくは、「リポジトリと組織のプッシュ保護」を参照してください。

このシリーズの次の記事については「フェーズ 3: パイロットプログラム」を参照してください。

この記事の内容