GitHubは2026年10月19日、異常なトラフィックが発生した際、HTTPS経由で公開リポジトリを取得する一部の操作に、一時的に認証を求めると発表しました。対象となる操作は失敗し、認証が必要であることを示すメッセージが表示されます。公開リポジトリ全般を認証必須にする変更ではありませんが、認証なしで取得する自動処理は設定の確認が必要です。
一部のclone・fetchを一時的に制限
対象は、HTTPSという暗号化された通信経路を使うGit操作のうち、公開リポジトリの一部のcloneとfetchです。cloneはリポジトリを手元に複製する操作、fetchは更新情報を取得する操作を指します。
GitHubによると、目的はgithub.comを利用できる状態に保つことです。異常なトラフィックに関連する兆候を使い、保護措置の適用範囲を極力絞ります。ただし、兆候が共通していると、正当な認証なしの操作も影響を受ける場合があります。
対象の操作が失敗した場合は、認証してから再試行する方法を案内しています。もう一つの方法は、一時的な保護措置が解除されるのを待ち、認証せずに再試行することです。認証要求が出たという理由だけで、公開リポジトリ全体の利用条件が変わったと判断しないことが大切です。
保護措置の適用対象は、全プランのgithub.com上のリポジトリです。日本向けの提供条件や、地域別の適用の違いは発表には書かれていません。
自動取得では認証設定を推奨
GitHubは、自動でclone・fetchを行う処理の安定性を高めるため、認証設定を推奨しています。確認したいのは、開発者が手動で取得できるかだけでなく、ビルドやテストなどの自動処理が認証なしの取得に依存していないかです。
継続的インテグレーションと呼ばれる、ビルドやテストなどを自動実行するCIの環境ごとに、案内されている認証方法は異なります。GitHub Actionsでは、組み込みのGITHUB_TOKENの利用を案内しています。
他のCIシステムでは、GitHub Appのインストールアクセストークンを優先するよう推奨しています。個人用アクセストークンも利用可能です。自社の処理がどちらの環境で動いているかを分けて確認すると、対応を整理できます。
影響する会社・しない会社
- 影響する: github.comの公開リポジトリに対し、認証なしでHTTPSのclone・fetchを行う会社です。一部の操作が保護措置の対象となる可能性があります。全プランが対象のため、プランだけでは対象外と判断できません。
- 影響する: 自動処理で認証なしのclone・fetchを使っている会社です。対象になった操作は失敗するため、取得処理と失敗時の扱いを確認する必要があります。
- 影響しない: 認証済みのHTTPS経由のGit操作、またはSSH経由のGit操作を使う処理です。これらは今回の措置の影響を受けません。
- 影響しない: push、および今回の措置と無関係なGitHubのWeb・APIトラフィックです。取得処理の失敗を、これらの操作にも及ぶ制限として扱う必要はありません。
情シスが今日やること
- 今日中に開発・運用担当へ確認を依頼します。 GitHub Actionsのワークフロー設定や、他のCIシステムのジョブ設定で、github.comからclone・fetchする処理を洗い出します。HTTPSかSSHか、HTTPSなら認証済みかを記録します。
- 失敗している処理の実行ログを確認します。 認証が必要であることを示すメッセージが出ていないかを調べます。公開リポジトリだから認証は不要なはず、と決めつけず、取得方法と認証の有無を担当者に確認します。
- 次回の自動実行前に認証方法を検討します。 GitHub ActionsはGITHUB_TOKEN、他のCIはGitHub Appのインストールアクセストークンを優先する案内を担当者に共有します。個人用アクセストークンも利用可能ですが、発表を根拠に全環境で同じ方法へ一律変更する必要はありません。
- 影響を受けた処理の再実行方針を決めます。 認証して再試行するか、保護措置の解除を待って認証なしで再試行するかを、開発・運用担当と決めます。社内への連絡では、公開リポジトリ全般の認証必須化ではないことと、確認できた対象処理を分けて伝えます。