何が変わったのか。全員向けの機能ではない

GitHubは2026年10月12日、コミットをpushした認証済みユーザーを継続的に記録し、作者・確定者の情報と並べてUIやAPIに示す機能を発表しました。名称は push attribution です。

発表時点ではGitHub Enterprise顧客向けの限定パブリックプレビューです。参加希望者は担当窓口へ問い合わせる案内であり、Free・Pro・Teamの全リポジトリで使える、あるいは既存の全履歴へ遡って表示されるとは断定できません。発表日と自分の環境で利用できた日は分けて記録します。

この記事では公式資料を確認していますが、新機能を実際に導入・検証していません。契約や権限を追加購入する案内ではなく、変更履歴を何の証拠として読めるかを整理します。

author・committer・pusherは別の情報

  • author（作者）：変更の作者としてコミットに保存される名前・メールなどの情報。
  • committer（確定者）：そのコミットを確定した側として保存される情報。作者と一致するとは限りません。
  • pusher（pushしたアカウント）：GitHubへの反映時に認証されたアカウント。今回の新機能が別途記録する対象です。
  • 署名の検証状態：署名が検証できたかという情報。作者欄やpushしたアカウントとは確認対象が違います。

Git公式マニュアルは、作者・確定者の情報を設定や環境変数から取得し、名前は認証に影響しないと説明しています。作者名が知っている担当者だから、実際にその担当者がログインして反映した、と結論づけることはできません。

当サイトのたとえでは、作者欄は「荷物に書かれた作成者」、pusherは「受付で認証した配送者」、レビューは「中身を点検する工程」です。役割はつながっていますが、どれか一つで他の確認まで済んだことにはなりません。このたとえはGitHub内部の実装説明ではありません。

新しいルールが防ぐことと、防げないこと

公式発表には Committer must match pusher という新しい条件もあります。committerのメタデータが、認証されたpusherの検証済みメールのいずれとも一致しないpushを拒否するものです。名前が似ているかを見るルールでも、authorとpusherを一律に同一人物へそろえるルールでもありません。

当サイトの評価として、記録上の確定者と実際の反映アカウントを結び付けることは、なりすましの経路を減らし、調査時に「誰の認証で入った変更か」をたどる助けになります。ただし、アカウント自体が乗っ取られていた場合や、そのアカウントが悪意ある内容を反映した場合まで、これだけで無害になるわけではありません。

一律に厳しくする前に、人の操作、bot、CI、代理反映など現在の正当な作業を把握します。rulesetの公式資料にあるように、利用条件・権限・適用対象・例外も別途確認が必要です。既存rulesetが使えることを、新プレビューも利用できる証拠にはしません。

Verifiedは「コードが安全」の印ではない

GitHubの署名資料では、GPG・SSH・S/MIMEなどの検証可能な署名を扱います。通常のVerified表示は、署名付きコミットの署名検証が成功したという意味です。Web UIで作成するコミットはGitHubが署名する仕組みもあります。

当サイトの判断上の注意として、署名の成功と、変更内容のレビュー・テスト・脆弱性の有無は別です。「Verifiedだから中身を見なくてよい」「署名がないから直ちに攻撃」とは扱いません。署名・反映アカウント・承認・実際の差分が、それぞれ何を確認できたのかを残します。

読み取り専用で始める点検手順

次は当サイトが提案する運用例です。新機能の操作実証や、全プラン共通の画面手順ではありません。

  1. 対象を固定する：正しい所有者・リポジトリ・ブランチと、調べたいコミットを確認する。似た名前の別案件を混ぜない。
  2. 差分を見る：設定、公開範囲、依存関係、権限に関わる変更が、依頼と承認の範囲内か確かめる。
  3. 記録を分ける：作者、確定者、署名状態、利用できる場合のpusherを別々に読む。表示できない項目は「未確認」とする。
  4. 正当な経路と照合する：関連するレビュー、承認、CI結果、利用可能なログ、デプロイのコミットを対応付ける。記録の保存期間や権限にも注意する。
  5. 不一致の理由を調べる：代理反映、共同作業、自動化などの説明があるか、担当へ確認する。不一致だけで侵害と断定しない。
  6. 変更するなら別に承認する：新しいルールは、承認済みの検証環境で正常な反映・拒否・例外・戻し方を確かめてから検討する。点検中に本番権限を不用意に変えない。

pushしたアカウントを調べるために、トークンや秘密鍵を提出させる必要はありません。秘密値をログや公開の質問欄へコピーせず、アクセスできる非秘密の記録で確認します。

架空例：担当Aの名前なのに、別アカウントが反映していた

架空のWebサービスで「担当A」が作者欄にあり、反映記録は「保守用アカウントB」だったとします。これだけで、なりすましとは決められません。担当Aが作成し、保守担当が承認済みの変更を反映した可能性もあります。

一方、予定にない公開設定の変更があり、承認も説明も見つからない場合は、作者名が見慣れていても調査対象です。差分・時刻・承認・デプロイの対応を確認し、アカウントと権限の点検へ進めます。認証済みアカウントの記録は調査の出発点であり、操作した実際の人の意思や端末の健全性を保証するものではありません。

点検記録の見本と未確認事項

  • 対象：架空のWebサービス、公開用ブランチの特定コミット。
  • 変更内容：公開設定の変更。依頼・承認と一致するか確認する。
  • 記録：作者・確定者・署名・反映アカウント・CI・デプロイを分けて記載する。実名や実メールは公開見本に使わない。
  • 未確認：プレビュー利用可否、過去履歴の扱い、取得できる記録、正当な自動化への影響。
  • 次の作業：説明できない変更は担当者へ確認し、必要なら組織のインシデント対応手順に従う。

便利なのは、信用する情報を増やすだけでなく、「表示されている名前」と「認証された反映経路」を混同しにくくなることです。契約対象外の人も、差分・レビュー・署名・公開コミットの対応を整理するところから始められます。今回、当サイトのリポジトリ権限・署名設定・rulesetは変更していません。