エンタープライズ試用版のお試し GitHub Code Security

          GitHub Code SecurityのGitHub Enterprise Cloudで使用できるコードと依存関係スキャンの機能の概要。ビジネス ニーズに合わせて評価できます。

この記事で

このガイドでは、エンタープライズ アカウントの既存 GitHub Advanced Securityまたは試用版のGitHubの試用を計画して開始していることを前提としています。GitHub Advanced Security の試用版を計画する を参照してください。

イントロダクション

          Code scanning と依存関係分析は、パブリック リポジトリと、 Code Security が有効になっているプライベート リポジトリと内部リポジトリで同じように機能します。 さらに、 Code Security を使用すると、セキュリティ スペシャリストと開発者が共同作業して技術的負債を効果的に削減できるセキュリティ キャンペーンを作成できます。

この記事では、これらの機能を Enterprise レベルの制御と組み合わせて、開発プロセスを標準化して適用する方法について説明します。

セキュリティ構成を調整する

通常、1 つのセキュリティ構成がすべてのリポジトリに適用される Secret Protectionとは異なり、さまざまな種類のリポジトリに対して code scanning の構成を微調整することが必要な場合があります。 たとえば、次のようにするために追加の構成の作成が必要な場合があります。

  •         Code scanning では、特定のラベルを持つランナーを使用して、特殊な環境を必要とするリポジトリやプライベート レジストリを使用するリポジトリに適用します。

  •         Code scanning は、高度なセットアップを使用する必要があるリポジトリ、またはサードパーティのツールを必要とするリポジトリに適用する場合は "未設定" です。

試用のためには、Enterprise レベルのプライマリ セキュリティ構成を作成してテスト リポジトリに適用するのが最も簡単です。 その後、必要な追加のセキュリティ構成を作成し、コード言語、カスタム プロパティ、可視性、その他のフィルター オプションを使って、選択したリポジトリのサブセットに適用できます。 詳細については、「試用版 Enterprise でセキュリティ機能を有効にする」および「カスタム セキュリティ構成の適用」を参照してください。

          code scanningの結果を表示するためのアクセス権を提供する。

既定では、リポジトリ管理者と組織の所有者のみが、その領域内のすべての code scanning アラートを表示できます。 試用の間に検出されたアラートにアクセスできるようにする、organization のすべてのチームとユーザーに、定義済みのセキュリティ マネージャー ロールを割り当てる必要があります。 試用に参加している各 organization の Enterprise アカウント所有者にこのロールを付与することもできます。 詳細については、「組織でのセキュリティマネージャーの管理」および「組織の役割の使用」を参照してください。

既定のセットアップの結果を評価して調整する

          code scanningの既定の設定では、一連の信頼度の高いクエリが実行されます。 これらは、コードベース全体で code scanning をロールアウトするときに、開発者が少数の誤検知結果を含む限られた高品質の結果セットを見られるようにするために選択されます。

評価版企業の組織で見つかった結果の概要は、企業の [ Security ] タブで確認できます。 セキュリティ アラートの種類ごとに個別のビューもあります。 「セキュリティの分析情報の表示」を参照してください。

          code scanningで予想される結果が表示されない場合は、既定のセットアップを更新して、より多くの結果が見つかると予想されるリポジトリ用の拡張クエリ スイートを実行できます。 これはリポジトリ レベルで制御されます。「[AUTOTITLE](/code-security/code-scanning/managing-your-code-scanning-configuration/editing-your-configuration-of-default-setup)」をご覧ください。

ヒント

          code scanningのリポジトリ設定の編集がブロックされている場合は、設定が適用されないように、リポジトリで使用されるセキュリティ構成を編集します。

それでも拡張スイートで予想される結果が見つからない場合は、分析を完全にカスタマイズできるように、高度なセットアップを有効にすることが必要な場合があります。 詳細については、「コード スキャンにツールの状態ページを使用する」および「コード スキャンの詳細設定を構成する」を参照してください。

pull request の自動分析を適用する

          GitHubに組み込まれている pull request の自動分析には、次の 3 種類があります。

* ** Code scanning 分析** では、クエリを使用して、既知の不適切なコーディング パターンとセキュリティの脆弱性が強調表示されます。 Copilotの自動修正 は、 code scanningによって識別される問題の修正を提案します。 * 依存関係レビューは、pull request によって行われた依存関係の変更を要約し、既知の脆弱性がある依存関係、または開発標準を満たしていない依存関係を明示します。 * ** Copilot コード レビュー** では、AI を使用して、可能な限り修正候補を含む変更に関するフィードバックを提供します。

これらの自動レビューは、自己レビューに対する重要な拡張機能であり、開発者がピア レビューのためにより完全で安全な pull request を提示しやすくします。 さらに、コードのセキュリティとコンプライアンスを保護するために、 code scanning と依存関係のレビューを適用できます。

メモ

          GitHub Copilotの自動修正 は、 GitHub Code Securityのライセンスに含まれています。 

          Copilot コード レビューには有料の Copilot プランが必要です。


          Code scanning 分析

          code scanning有効にすると、プル要求が要件を満たしていない限り、企業または組織のコード ルールセットを作成して、重要なブランチへのマージをブロックできます。 通常、 code scanning からの結果が存在し、重要なアラートが解決される必要があります。

* ルールセットの種類: ブランチ。 * ** code scanning結果の要求:** 結果がコミットおよびプル要求のターゲット参照に対して正常に生成されるまで、マージをブロックすることを有効にします。 * 必要なツールとアラートのしきい値: 使用する各 code scanning ツールに対してプル要求をマージする前に解決する必要があるアラートのレベルを定義します。

他のすべてのルールセットと同様に、対象の organization (Enterprise レベル)、リポジトリ、ブランチを正確に制御でき、ルールをバイパスできるロールまたはチームを定義することもできます。 詳しくは、「ルールセットについて」をご覧ください。

依存関係レビュー

リポジトリに対して Code Security と依存関係グラフが有効になっている場合、マニフェスト ファイルには、追加または更新される依存関係の概要を示す豊富な差分ビューがあります。 これは、pull request の人間のレビュー担当者にとっては便利な概要ですが、コードベースに追加される依存関係を制御することはできません。

ほとんどの Enterprise では、自動チェックを実施して、既知の脆弱性またはサポートされていないライセンス条項を含む依存関係の使用をブロックします。

  1. Enterprise の再利用可能なワークフローを格納できる中央のホームとして機能するプライベート リポジトリを作成します。
  2. リポジトリのアクション設定を編集して、Enterprise 内のすべてのプライベート リポジトリがこの中央リポジトリ内のワークフローにアクセスできるようにします。「プライベート リポジトリ内のコンポーネントへのアクセスを許可する」をご覧ください。
  3. 中央リポジトリで、依存関係レビュー アクションを実行する再利用可能なワークフローを作成し、ビジネス ニーズに合わせてアクションを構成します。「依存関係レビュー アクションの構成」をご覧ください。
  4. 各 organization で、ブランチ ルールセットを作成または更新して、新しいワークフローを必要なステータス チェックに追加します。「organization 全体で依存関係レビューを実施する」をご覧ください。

これにより、構成の更新を 1 か所で行いながら、多くのリポジトリでワークフローを使用できます。 この中央リポジトリを使って、他のワークフローを維持することもできます。 詳しくは、「ワークフローを再利用する」をご覧ください。

Copilotコード レビュー

メモ

  • 組織からCopilotサブスクリプションを取得した場合、組織または企業の所有者がパブリック プレビューを有効にしている場合にのみ、GitHub Web サイトのCopilotコード レビューに参加できます。 ドキュメントの 企業での GitHub Copilot のポリシーと機能の管理 と GitHub Enterprise Cloud を参照してください。

既定では、ユーザーは人間の校閲者から行うのと同じ方法で、 Copilot にレビューを要求します。 ただし、組織レベルのブランチ ルールセットを更新または作成して、すべてのリポジトリまたは選択したリポジトリ内の選択したブランチに対して行われたすべてのプル要求に、レビュー担当者として Copilot を自動的に追加できます。 ドキュメントの GitHub Enterprise Cloud を参照してください。

          Copilot pull request を承認したり変更を要求したりすることなく、レビューする各プル要求にレビュー コメントを残します。 これにより、そのレビューはアドバイスとなり、開発作業をブロックすることはありません。 同様に、AI の提案には既知の制限があるため、Copilotによって行われた提案の解決を強制しないでください。[](/enterprise-cloud@latest/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-code-review#limitations-of-github-copilot-code-review)ドキュメントの GitHub Enterprise Cloud を参照してください。


          Copilotの自動修正を許可して有効にする場所を定義する

          Copilotの自動修正 は、開発者がプル要求で見つかった code scanning アラートを理解して修正するのに役立ちます。 開発者がアラートを効率的に解決し、セキュリティで保護されたコーディングに対する理解を深めるために、 Code Security が有効になっているすべてのリポジトリでこの機能を有効にすることをお勧めします。

制御には次の 2 つのレベルがあります。

開発者をセキュリティの修復に参加させる

セキュリティ キャンペーンは、セキュリティ チームが開発者と連携してセキュリティの技術的負債を修復する方法を提供します。 また、安全なコーディングでの教育と、開発者が使い慣れたコードでの脆弱なコードの例を組み合わせる実用的な方法も提供します。 詳細については、ドキュメントの「AUTOTITLE」と「GitHub Enterprise Cloudを参照してください。

セキュリティで保護された開発環境を提供する

開発環境には多くのコンポーネントがあります。 GitHubでのセキュリティで保護された開発環境のスケーリングと標準化に最も役立つ機能の一部を次に示します。

  •         **セキュリティ構成:** エンタープライズ、組織、組織内のリポジトリサブセット、または新しいリポジトリのセキュリティ機能の設定を定義します。「[セキュリティ構成を調整する](#refine-your-security-configurations)」をご覧ください。

  •         **ポリシー:** Enterprise または organization のリソースの使用を保護および制御します。「[AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise)」をご覧ください。

  •         **ルールセット:** 組織、組織のリポジトリのサブセット、またはリポジトリのブランチ、タグ、プッシュを保護および制御します。「[AUTOTITLE](/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization)」をご覧ください。

  •         **リポジトリ テンプレート:** 環境の種類ごとに必要なセキュリティ ワークフローとプロセスを定義します。「[AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-template-repository)」をご覧ください。 たとえば、各テンプレートには特殊化された次のものが含まれる場合があります。
    • 会社のセキュリティに対する取り組みとセキュリティに関する懸念を報告する方法を定義するセキュリティ ポリシー ファイル。
    • 会社が使用するパッケージ マネージャーの Dependabot version updates を有効にするワークフロー。
    • 既定のセットアップ結果では不十分な、サポートされている開発言語の code scanning の詳細設定を定義するワークフロー。

さらに、開発者がテンプレートからリポジトリを作成するときに、必要なカスタム プロパティの値を定義する必要があります。 カスタム プロパティは、構成、ポリシー、またはルールセットを適用するリポジトリのサブセットを選択する場合に非常に便利です。ドキュメントの GitHub Enterprise Cloud を参照してください。

次のステップ

これらのオプションと secret scanning 機能の探索が完了したら、これまでの発見をビジネス ニーズに照らしてテストし、さらに詳しく調べる準備が整いました。

詳細については、次を参照してください。

  •         [AUTOTITLE](/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions)

  •         [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise)

  •         [AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/governing-how-people-use-repositories-in-your-enterprise)GitHub Enterprise Cloudドキュメント

  •         [大規模に GitHub Advanced Security を実施する](https://wellarchitected.github.com/library/application-security/recommendations/enforce-ghas-at-scale/)