組織のセキュリティ保護

はじめに

組織所有者またはセキュリティマネージャーは、GitHub のセキュリティ機能を使って、組織のコード、依存関係、シークレットを安全に保つことができます。詳しくは、「GitHub セキュリティ機能」を参照してください。

セキュリティのニーズは組織によって異なります。特定の機能によって防がれたであろう脆弱性の影響を組織が受けている場合、または組織がコンプライアンス要件を満たすために機能が役に立つ場合は、機能を有効にすることが必要になる場合があります。

組織内の複数のリポジトリで同時にセキュリティ機能を有効にできます。有効にする機能ごとに、組織のリポジトリ間に機能をロールアウトする方法を決める必要があります。機能が異なれば、組織とその共同作成者に及ぼす影響も異なるため、機能ごとに影響を評価することが重要です。次に例を示します。

一部の機能では、特定の脆弱性について組織のメンバーに知らせる通知を生成できます。これらの通知の対象と関連性を確実にするため、機能を有効にする前に、メンバーに通知の設定をチェックするよう依頼することが必要な場合があります。詳しくは、「通知を設定する」を参照してください。
機能によっては、有効にされたリポジトリごとのリソースを消費する可能性があります。たとえば、プライベートリポジトリで code scanning を有効にすると、GitHub Advanced Security ライセンスが消費される場合があり、リポジトリで code scanning 分析を実行すると、GitHub Actions またはその他の CI システムが使われます。

組織所有者は、"セキュリティマネージャー" ロールをチームに割り当てることで、セキュリティ機能を有効または無効にするアクセス許可を特定のユーザーに付与できます。セキュリティマネージャーは、セキュリティ設定を構成し、組織全体のセキュリティ機能の使用状況を監視できます。詳しくは、「Organizationでのセキュリティマネージャーの管理」を参照してください。

機能の前提条件について

一部のセキュリティ機能には前提条件があります。たとえば、Dependabot alerts は依存関係グラフの情報を使うため、Dependabot alerts を有効にすると、依存関係グラフが自動的に有効になります。

一部の機能は、パブリックリポジトリでは既定で有効にされます。プライベートリポジトリでは、一部の機能は GitHub Advanced Security を使用し、リポジトリの機能として Advanced Security を有効にしているエンタープライズでのみ使用できます。詳しくは、「GitHub Advanced Security について」を参照してください。

リポジトリごとに個別に構成する必要がある機能がいくつかあります。たとえば、リポジトリで Dependabot version updates を有効にするには、プロジェクトの依存関係に関する情報を検索する場所を指定する dependabot.yml ファイルを追加する必要があります。詳しくは、「Dependabot のバージョンアップデートの設定」を参照してください。

組織でセキュリティ機能を有効にする

セキュリティ機能を有効にすることを決めたら、次のステップは、組織全体にその機能をロールアウトする方法を決めることです。

機能をできるだけ速くロールアウトしたい場合は、対象となるすべてのリポジトリに対して一度に有効にできます。詳しくは、「すべてのリポジトリで機能を有効にする」をご覧ください。
機能をロールアウトする速度と、どの機能をどのリポジトリで有効にするかを制御したい場合は、リポジトリを選んで機能を有効にできます。詳しくは、「選択したリポジトリで機能を有効にする」をご覧ください。

組織の既存のリポジトリで機能を有効にする方法を決めたら、将来組織で作成される新しいリポジトリを処理する方法も決める必要があります。詳しくは、「新しいリポジトリで機能を有効にする」をご覧ください。

すべてのリポジトリで機能を有効にする

セキュリティ機能を最も短時間でロールアウトする方法は、組織内のすべてのリポジトリに対して一度に有効にすることです。機能の重要なニーズが明らかになっている場合は、すべてのリポジトリでそれを有効にすると、作業を止めてロールアウト計画を立てる必要がなく、組織全体に保護が提供されます。

すべてのリポジトリで機能を有効にする前に、このアクションによる影響を考慮する必要があります。機能の影響がわからない場合は、限られたリポジトリを選んで機能を有効にすることから始めるのが最も安全です。次の状況では、すべてのリポジトリで一度に機能を有効にするのが適切なオプションである可能性があります。

組織内のすべてのリポジトリの概要がわかっていて、それらのすべてが特定の機能の恩恵を受けることが確実である。
GitHub Advanced Security ライセンスや GitHub Actions 分などのリソースが機能に必要な場合は、必要なリソースの評価が済んでおり、続けても問題ない。
機能が通知または pull request を生成する場合、それが受け取るメンバーやレビューする必要があるメンバーを対象としたもので、関連性があることが確実である。

続ける準備ができたら、次の手順のようにして、すべてのリポジトリで機能を有効にします。

GitHub.com で、Organization のメインページへ移動します。
組織名の下で、 [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
左側のサイドバーで、 [コードのセキュリティと分析] をクリックします。
有効にする機能を見つけ、関連付けられているチェックボックスを使用してオプションを微調整します。
機能がサポートされている組織内のすべてのリポジトリで機能を有効にする準備ができたら、機能の名前の横にある [すべて有効にする] をクリックします。

[すべて有効にする] をクリックすると、選択を確認するメッセージが表示されます。また、その機能が別の機能に依存しているかどうか、または GitHub Advanced Security を必要とするかどうかを確認するメッセージも表示されます。詳しくは、「組織のセキュリティおよび分析設定を管理する」を参照してください。

選択したリポジトリで機能を有効にする

状況によっては、機能を必要とするリポジトリを特定して選択し、それらのリポジトリに対してだけ機能を有効にする方がよい場合があります。

機能の影響がわからない場合は、すべてのリポジトリで機能を有効にする前に、限られたリポジトリを選んで機能をテストするか、複数のフェーズで機能を段階的にロールアウトすることができます。また、組織内の一部のリポジトリでは、他とは異なる機能セットが必要であることが、分かっている場合もあります。

機能を必要とするリポジトリを特定したら、各リポジトリで個別に機能を有効にできます。組織所有者またはセキュリティマネージャーは、組織内の各リポジトリのセキュリティ設定を構成できます。詳しくは、「リポジトリを保護する」を参照してください。

GitHub Enterprise Cloud 上の組織の場合は、"セキュリティカバレッジ" ビューを使って機能が必要なリポジトリを特定した後、それらのリポジトリで機能を有効にできます。詳しくは、GitHub Enterprise Cloud のドキュメントの「複数のリポジトリでセキュリティ機能を有効にする」をご覧ください。

新しいリポジトリで機能を有効にする

組織で作成されるすべての新しいリポジトリで、セキュリティ機能を自動的に有効にすることを選択できます。新しいリポジトリで機能を有効にすると、リポジトリがすぐに保護され、可能な限り速やかにリポジトリ内の脆弱性が識別されます。ただし、セキュリティ機能を可能な限り効率的に使用するには、新しい各リポジトリを個別に確認する方がよい場合があります。

GitHub.com で、Organization のメインページへ移動します。
組織名の下で、 [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
左側のサイドバーで、 [コードのセキュリティと分析] をクリックします。
機能の名前の下で、該当する将来のリポジトリで機能を自動的に有効にするオプションを選びます。

セキュリティ機能の影響を監視する

機能を有効にしたら、組織のリポジトリ管理者と共同作成者に連絡し、機能の影響を評価する必要があります。リポジトリレベルで一部の機能の構成を調整したり、組織全体のセキュリティ機能の分散を再評価したりすることが必要な場合があります。また、機能によって生成されるセキュリティアラートと、これらのアラートに対するメンバーの応答も、監視する必要があります。

GitHub Enterprise Cloud を使用する組織は、セキュリティの概要を使って、重大度別のアラートの内訳により、セキュリティアラートの影響を受けるチームとリポジトリを確認できます。詳しくは、GitHub Enterprise Cloud ドキュメントの「コードセキュリティリスクの評価」をご覧ください。

さまざまなツールを使って、組織のメンバーがセキュリティアラートに応答して実行しているアクションを監視できます。詳しくは、「セキュリティアラートの監査」をご覧ください。

次のステップ

ユーザーがセキュリティの脆弱性を報告するのに役立つよう、独自のセキュリティポリシーを持たない組織のパブリックリポジトリに表示される、既定のセキュリティポリシーを作成できます。詳しくは、「既定のコミュニティ正常性ファイルの作成」を参照してください。

組織のセキュリティ保護

この記事の内容