📌

Catch-up! 週刊 GitHub updates（2024年2月19-25日）

2024/02/26に公開

GitHub

tech

GitHub Changelog for Feb 19 - 25, 2024

こんにちは、@dz_ こと、岩永かづみです。

先週のGitHub Changelogの週刊キャッチアップをお届けします。

Secret scanningのvalidity checksでMailgunとMailchimpをサポート

Secret scanningのvalidity checkで、Mailgun（mailgun_api_key）とMailchimp（mailchimp_api_key）のAPIキーをサポートしました。

Validity checksは、漏洩したクレデンシャルがactiveでまだ利用できる状態かどうかを示します。もしリポジトリで事前にvalidity checksを有効にしていれば、GitHubはサポートされたトークン型のアラートに対して自動的に検証します。

Validity checksは、GitHub Enterprise CloudのGitHub Advanced Securityが適用されたリポジトリで利用できます。organizationレベルおよびリポジトリレベルの両方で、「Code security and analysis」設定ページから、「automatically verify if a secret is valid by sending to the relevant partner.」のオプションをチェックすることでこの機能を有効化できます。

Secret scanningやvalidity checksでサポートするパターンについて、ご確認ください。

CodeQL 2.16.2: Android向けの新しいクエリと正確性の向上

CodeQL 2.16.2について、GitHub.com上のGitHub code scanningを利用するユーザーが利用可能になり、すべての新しい機能はGitHub Enterprise Server(GHES) 3.13に含まれる予定です。GHES 3.12以前のユーザーはCodeQLのバージョンをアップグレードしてください。

このリリースにおける重要な変更は以下の通りです。

新しいJavaとAndroid向けのクエリを追加（java/android/sensitive-textとjava/android/sensitive-notification）。テキストフィールドや通知からのセンシティブなデータの漏洩を検知する。
いくつかのC/C++クエリにおける正確性の向上
C# 12のコレクション記法を認識できるように（例： [1, y, 4, .. x]）

変更についての詳細は、version 2.16.2の完全なchangelogをご参照ください。

GitHub Appsにおけるスコープ付きトークン作成の新しい制限

GitHub.comの可用性を保護するための積極的な手段として、GitHub Appsが複雑なスコープ付きのinstallationトークンの作成を試みた場合、その対象のリポジトリが多すぎると失敗するようになります。今回リリースする制限は既存の消費量のおよそ8倍で設定されており、現時点では、この制限を超えるGitHub Appsはありません。複雑さの計算については、以下を参照ください。

スコープ付きトークンを使用すると、GitHub Appは、アプリケーションがorganizationの中で利用できる権限のサブセット（縮小したリポジトリのセットやパーミッションなど）を持たせたinstallationトークンを作成できます。この方法で、多くのパーミッションを持ち多くのリポジトリへのアクセスを必要とするアプリケーションは、その時必要なアクセスのみに適したトークンを安全にリクエストできます。これは、有用な最小限の権限を付与する機能です。

スコープ付きトークンをリクエストするとき、アプリケーションは必要なパーミッションとリポジトリの両方を指定します。これらのパラメーターはオプションで、もしどちらも省略されたときは（アプリケーションに与えられた）全てのパーミッションとアクセス可能なリポジトリに対するアクセス権がトークンに与えられます。

今回追加される制限のうち1つは、トークンリクエストにリポジトリが含む場合に、500個以上のリポジトリを扱えなくなります。

もう1つの制限は、リポジトリを指定しないがパーミッションを指定する場合で、かつアプリケーションがorganization内の「一部」のリポジトリにインストールされている場合に適用されます（organization内のすべてのリポジトリに対するアクセス権を明示的に指定していない場合など）。

このケースでは、リクエストされたパーミッションの数とアプリケーションがアクセス権を持つリポジトリの数に基づいて制限されます。もし複雑さの制限を越えた場合、アプリケーションはToo many repositories for installationというエラーを受け取り、アプリケーションが正常にアクセスできるリポジトリの最大数やまたはトークンの複雑さを下げるための他の選択肢を提供します。

トークンリクエストの複雑さを下げるには、以下を検討してください。

organizationにおけるアプリケーションがアクセス権を持つリポジトリの数を減らす
トークンで要求するパーミッションの数を減らす
アプリケーションのアクセス権を、organizationにおける「すべて」のリポジトリに対して設定する
スコープ付きトークンを利用せず、標準のinstallationトークンを利用する

これらの選択肢のどれもがトークンの複雑さを下げ、再びアプリケーションがorganizationに対するトークンを取得できるようになります。

GitHub Appのスコープ付きトークンの発行とインストールについての詳細は、以下のどきゅ面をご参照ください。

Secret scanningがEnterprise Managed Usersのユーザーの名前空間におけるリポジトリをサポート

Enterprise Managed Usersにおいて、シークレットスキャニング（secret scanning）がユーザーの名前空間におけるリポジトリに適用できるようになりました。ユーザーリポジトリの所有者は、リポジトリでサポートされるシークレットが検知されたとき、シークレットスキャニングアラートを受け取るようになります。ユーザーの名前空間におけるリポジトリでも、プッシュ保護（push protection）を利用できます。

エンタープライズレベルのシークレットスキャニングアラートの一覧では、エンタープライズの所有者はユーザーの名前空間におけるリポジトリで検知された全てのシークレットを閲覧できます。エンタープライズの所有者は、シークレットの詳細を閲覧するためにユーザーの名前空間におけるリポジトリに一時的にアクセスできます。

ユーザーの名前空間におけるリポジトリは、セキュリティのリスクやカバレッジページに含まれるようになります。

シークレットスキャニングは、GHES 3.13から、Enterprise Serverの個人のリポジトリもサポートする予定です。

詳しくは下記をご参照ください。