GitHubは2026年10月13日、GitHub Appsの権限と管理機能の改善を発表しました。リポジトリの作成やアプリのアクセス先の変更に、用途を絞った権限を使えるようにします。従来型の個人用アクセストークン(PAT)からの移行と、機密性の高い権限の削減が狙いです。
作成とアクセス先管理を、用途別の権限に分離
必要な操作だけを許可する「最小権限」の管理に向け、新しい2種類の権限を追加しました。対象はGitHub Appsと、権限を細かく指定するfine-grained PATです。
repository_creation:writeでは、コードなどを保管するリポジトリの作成だけを許可できます。従来の作成用権限には、削除や移管の権限も含まれていました。作成処理のために広い権限を付けている場合は、見直しの候補になります。
ただし、作成したアプリまたはユーザーには、そのリポジトリへのアクセスが付きます。また、作成権限を使うアプリのインストールには、引き続き組織管理者が必要です。作成専用になっても、作成後のアクセスや導入時の承認まで不要になるわけではありません。
もう一つのinstallation_repositories:writeは、アプリの導入設定にリポジトリを追加・削除するAPIに使います。APIはプログラムから操作するための窓口です。このAPIがGitHub Appsとfine-grained PATに対応し、広範な権限の管理者PATに頼らず、アプリのアクセス先を自動管理できるようになります。
呼び出し元がユーザーの場合は、組織オーナーか対象リポジトリの管理者である必要があります。
承認の一部を緩和、期限付きトークンへの移行も支援
組織に導入済みの承認済みアプリについて、リポジトリ管理者が自分のリポジトリを既存の導入設定へ追加する際は、組織オーナーの再承認が不要になります。一方、組織レベルの全権限、リポジトリ管理、リポジトリ作成には、組織オーナーの承認が必要です。
GitHub Appsはoffline_accessにも対応しました。認証時にこのスコープを要求すると、有効期限付きのユーザーアクセストークンと更新トークンを受け取れます。既存の仕組みから、期限付きトークンへ段階的に移行するための機能です。
適用されるのは個別の認証だけで、以後のセッションには影響しません。アプリの権限も、引き続きアプリ登録時に固定的に選択します。今回の対応は、認証のたびにアプリの権限を自由に変える仕組みではありません。
認証情報の管理先は、専用の「Credentials」タブへ移りました。ワークロードフェデレーション向け認証情報の導入は今後の予定です。これは、処理を実行する環境の認証を連携させる仕組みで、今回提供済みの機能とは分けて扱う必要があります。
GHESでは、offline_access対応を3.23、その他の改善を3.24で提供予定です。日本での提供は発表には書かれていません。
影響する会社・しない会社
- 影響する: GitHub Appsやfine-grained PATでリポジトリを作成する会社です。削除・移管まで含む従来の権限を、作成専用権限へ見直す候補があります。
- 影響する: 管理者PATでアプリのアクセス先を自動管理する会社や、承認済みアプリへの追加を組織オーナーが都度承認している会社です。権限と申請手順の両方が点検対象です。
- 影響しない: GitHub Appsもfine-grained PATも使わない運用は、今回の新しい2種類の権限を使う対象ではありません。
- 影響しない: 組織レベルの権限やリポジトリ管理・作成に対する承認は、今回の緩和で不要にはなりません。対象プランや会社規模の条件は、発表には書かれていません。
情シスが今日やること
以下は、社内点検の進め方です。GitHubが指定した対応期限ではありません。
- 今日、開発部門の自動化担当者に、リポジトリ作成とアプリのアクセス先変更に使う認証方式を確認します。従来型PAT、fine-grained PAT、GitHub Appsを分け、管理者PATを使う処理を一覧にします。
- アプリ登録時の権限設定と、作成処理の実装を照合します。作成だけで足りる処理を
repository_creation:writeへの変更候補にし、作成後のアクセスも確認します。変更前にアプリ管理者と必要な操作を合意します。
- アクセス先を変更するAPIの呼び出し元を確認します。新権限への切り替え候補と、ユーザーの場合に必要な組織オーナー・リポジトリ管理者の条件を整理します。承認済みアプリの追加手順は、組織オーナーと開発部門へ共有します。
- GitHub Appsの管理画面では「Credentials」タブを確認し、認証情報を管理する社内手順書を見直します。offline_accessを使う予定があれば、アプリ担当者に期限付きトークンと更新トークンの扱いを確認してもらいます。
- GHES利用会社は、変更計画を立てる前に利用版と提供予定を照合します。3.23と3.24で対象機能が異なるため、すべての改善を同じ版で使える前提にしないでください。
