GitHub「push した人」を記録する新機能 限定プレビューの中身と監査の見方

GitHubは2026年10月12日、コミットを「だれが push したか」を記録して画面とAPIに出す機能を、限定の公開プレビューにしました。コミットはコードの変更を1つにまとめた記録、push は手元の変更を GitHub に送る操作です。作者名を偽って送られたコミットを、後から確かめやすくする狙いです。

何が見えるようになるのか

GitHubの変更履歴は、各コミットを push した認証済みのユーザーを残し、その名前を画面とAPIに出すと書いています。表示は、これまでの作者(author)とコミッター(committer)の欄の横に並びます。

コミットの作者名とメールアドレスは、送る側の git の設定で自由に書けます。変更履歴は、この点を理由にあげています。

Commit author and committer fields are just strings that the pushing client supplies, so anyone with write access to a repository can set them to any name and email they choose.

訳すと、作者とコミッターの欄は push する側が渡す文字列にすぎず、書き込み権限があれば、どんな名前とメールにもできる、という意味です。権限の低いアカウントを乗っ取った人が、信頼される保守担当者の名前でコミットを作り、審査の方針や監査の記録を混乱させる恐れがある、とも書かれています。

上の図は、公式ページに載っている画面の例です。「committed」の横に並んで「pushed」の表示が出ています。

公式の資料で確かめられたこと

管理者が必要な設定は、記録の表示については書かれていません。ルールを効かせるには、ルールセットに追加する必要があります。

今すぐできること(公式の資料にあるもの)

プレビューを待たなくても、公式のドキュメントにある対策があります。

• 署名の必須化。 ルールセットの「Require signed commits」を使うと、署名され、検証されたコミットだけが対象のブランチに push できます。検証できない場合、更新は受け付けられません。署名は、作者が自分の鍵でコミットに付ける印です。
• メールの形式の制限。 GitHub Enterprise のプランでは、コミッターや作者のメールが「@自社ドメイン」で終わることを、パターンで要求できます。ただし、これは書かれた文字列の形を見るだけです。他人のメールを書けば形は合います。
• 監査ログ。 組織の監査ログは、過去180日以内の操作を、実行者(actor)つきで見られます。標準の表示は直近3か月で、それより古いものは日付の範囲を指定します。見られるのはオーナーだけです。
• Git の操作の記録。 GitHub Enterprise Cloud では、Git のイベントはAPIだけで、保存は7日間と書かれています。

プレビューで足されること

足されるのは次の2つです。

1. push した人の記録が、各コミットについて残ること。作者とコミッターの記載に左右されません。
2. 「Committer must match pusher」のルール。コミッターのメールが、push した人の確認済みメールと合わなければ、push が止まります。

変更履歴は、後者を「コミットの身元の偽装につながる道をふさぐ」ものと書いています。また、疑わしい動きの確認や、セキュリティの調査を速くするために使えると書いています。

退職者のアカウント、共有アカウント、委託先、見覚えのないコミット。この4つの場面で、「この名前で作られたコミットを、実際に push したのはだれか」を画面やAPIで確かめられる、というのが編集部の理解です。ただし変更履歴は、これらの場面を例に挙げてはいません。(編集部の補足)

書かれていないこと

• 過去の push にさかのぼって記録されるか。
• fork、Webの画面からの編集、プルリクエストのマージで作られるコミットの扱い。
• 一般提供の予定日と、Enterprise 以外への提供。
• 記録の保存期間、監査ログへの出し方、APIの項目名。
• ルールが止めるのが、新しいコミットだけか、既存の履歴にも及ぶのか。

Webからの編集やマージで作られるコミットのコミッターは、別の仕組みで扱われます。たとえば、ルールセットのメール制限の説明には、GitHub上で作られるコミットのためのアドレス(noreply@github.com)をパターンに含める必要があると書かれています。プレビューのルールが、この種のコミットとどう組み合わさるかは、書かれていません。

影響する会社・しない会社

• 影響する: GitHub Enterprise を契約している会社。限定プレビューの対象で、アカウントチームに申し込めます。
• 影響する: 退職者・委託先・共有アカウントがリポジトリに書き込める会社。「作者の表示」だけで操作の主を判断していると、確かめ方がずれます。
• 影響しない: GitHub を使っていない会社、Free・Team など Enterprise 以外の契約の会社。プレビューの対象に入りません。拡大の予定は書かれていません。
• 影響しない: 全員が署名を必須とし、すでに監査の運用が回っている小規模なチーム。ただし、署名と push した人の記録は別のものです。

情シスが今日やること

1. 契約のプランを確認します。GitHub Enterprise なら、アカウントチームに、プレビューへの参加を依頼するかを開発責任者と決めます。
2. 書き込み権限を持つ人を一覧にします。退職者、委託先、共有アカウントが残っていないか、リポジトリの権限の画面で確認します。
3. 重要なブランチに「Require signed commits」を入れられるか、開発側に確認します。署名の鍵を持たない人がいる場合は、運用の手間も一緒に聞きます。
4. 組織の監査ログの見方を、オーナーの権限を持つ人と一度試します。実行者で絞る方法と、180日の期限を確かめます。Git のイベントは7日間しか残らないことも共有します。
5. 不審なコミットが見つかったときの手順を決めます。作者名だけで人を決めつけず、記録が見られる範囲で確かめる、と書いておきます。

公式の発表は、プレビューの条件を変えることがあります。申し込む前に、アカウントチームに、さかのぼりと fork の扱いを聞いてください。