Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-03-26. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

フェーズ 5: Code Scanning のロールアウトとスケーリング

使用可能な API を利用し、先ほど収集したリポジトリ データを使用して、企業全体で Team 別および言語別に code scanning をプログラムでロールアウトできます。

この記事は、GitHub Advanced Security の大規模な導入に関するシリーズの一部です。 このシリーズの前の記事については「フェーズ 4: 内部ドキュメントを作成する」を参照してください。

Code Scanning の有効化

フェーズ 2 で照合したデータを使用して、GHAS を有効にしてから、リポジトリで code scanning (一度に 1 つの言語) を有効にすることができます。 GHAS を有効にする手順は次のようになります。

  1. リポジトリで GHAS を有効にします。 詳しくは、「リポジトリのセキュリティと分析設定を管理する」を参照してください。
  2. その言語の CodeQL を実行する方法の例を含む codeql-analysis.yml ファイルを使って、リポジトリの既定のブランチに対して Pull Request を作成します。 詳しくは、「pull request の作成」を参照してください。
  3. リポジトリに Issue を作成して、Pull Request が発生した理由を説明します。 作成する Issue には、すべてのユーザーに送信された以前の通信へのリンクを含めることができますが、Pull Request が導入する変更、Team が実行する必要がある次の手順、Team の責任、Team が code scanning を使用する方法を説明することもできます。 詳しくは、「Issue の作成」を参照してください。

ghas 対応ツールと呼ばれる、最初の 2 つの手順を完了する一般公開されているツールがあります。 ghas 対応ツールは、意味のある言語のバッチで再実行できます。 たとえば、JavaScript、TypeScript、Python、Go はビルド プロセスが似ている可能性があるため、同様の CodeQL 分析ファイルを使用できます。 ghas 対応ツールは、Java、C、C++ などの言語にも使用できますが、これらの言語のビルドとコンパイルの方法は多様であるため、よりターゲットを絞った CodeQL 分析ファイルを作成する必要がある場合があります。

メモ: GitHub Actions を使用して code scanning を制御する予定であるが、ghas 対応ツールを使用しない場合は、.github/workflow ディレクトリへの API アクセス権がないことに注意してください。 つまり、自動化の基になる Git クライアントなしでスクリプトを作成することはできません。 回避策は、Git クライアントを持つマシンまたはコンテナーで bash スクリプトを利用することです。 Git クライアントは、codeql-analysis.yml ファイルが配置されている .github/workflows ディレクトリにファイルをプッシュおよびプルできます。

単にリポジトリの既定のブランチに codeql-analysis.yml ファイルをプッシュしないようにしてください。 Pull Request を使用すると、レビューおよびマージするために開発 Team に所有権が与えられ、開発 Team は code scanning について学習でき、Team がプロセスに関与するようになります。

自動化によって作成された Pull Request URL をキャプチャし、アクティビティを毎週確認して、どのアクティビティがクローズしているかを確認する必要があります。 数週間後に、Pull Request がマージされていない場合は、別の Issue を作成したり、内部メールを送信したりすると良いでしょう。

分野の専門知識を構築する

その後、社内の対象分野の専門家 (または SME) を作成し、社内会議を手配する次の段階に進むことができます。 リポジトリで Pull Request や Issue を開くと、導入の大部分に対応できる可能性があります。ただし、特定のビルド プロセス、フレームワーク、またはライブラリで特定の機能フラグを有効にする必要がある 1 回限りのユース ケースには対応できません。 特に Java、C、C++ に対する適合性を高めるには、よりパーソナライズされた実践的なアプローチが必要です。

特定のトピックに関して会社の会議を定期的に開き、より大きなグループとの間でロールアウトについて教育し議論することをお勧めします。 これは、一度に 1 Team ずつと作業する場合と比較して、何千ものリポジトリを持つ会社にとって、はるかに時間効率が高くなります。 Team は、関連するセッションに参加できます。 前に実行されたセッションの例を次に示します。

  • コンテナーの Code scanning
  • Code scanning と Java Struts
  • Code scanning と JSP

リポジトリ間での異なる言語の配布に関して収集したデータを使用して、対象となる会議を作成できます。

このシリーズの次の記事については「フェーズ 6: secret scanning のロールアウトとスケーリング」を参照してください。