GitHub 提交推送归因功能进入有限公测

GitHub 现在会持久记录推送每次提交的经认证用户，并在 UI 和 API 中把该推送者身份与现有的作者和提交者字段一起展示。

提交的作者和提交者字段只是推送客户端提供的字符串，因此任何拥有仓库写权限的人都可以把它们设置成自己选择的任何姓名和邮箱。这使得攻击者在攻陷一个低权限账号后，可以伪造出看起来来自可信维护者的提交，从而绕过审查策略并扰乱审计线索。

GitHub 本来就会对推送进行认证。本次发布在作者和提交者元数据之外，增加了持久的、按提交记录的推送者归因。现在推送到仓库的每一次提交都会附带一个持久的、经认证的推送者身份，与作者和提交者元数据所声称的内容无关。

一个名为“Committer must match pusher”的新仓库规则条件会拦截那些提交者元数据与经认证推送者的任何已验证邮箱地址都不匹配的推送。这堵住了一条提交身份伪造的路径。

你可以利用推送者身份来抽查可疑活动，或加快安全调查，而不必依赖未经验证的元数据。你能这样做，是因为推送者身份现在可以在所有展示提交的位置看到。

若要在某个仓库上强制执行更严格的身份要求，请把新的“Committer must match pusher”规则加入规则集。

推送归因目前以有限公开预览的形式提供给 GitHub Enterprise 客户。如果你有兴趣加入预览，请联系你的客户团队申请访问权限。了解有关配置推送规则集的更多信息。

GitHub 开始为每次推送持久记录经认证的推送者身份，并在 UI 和 API 中与作者、提交者字段并列展示；同时新增“Committer must match pusher”仓库规则，用于拦截提交者元数据与推送者已验证邮箱不匹配的推送，从而封堵提交身份伪造路径。该能力目前以有限公开预览形式面向 GitHub Enterprise 客户开放。

• GitHub 开始为每次推送持久记录经认证的推送者身份，并在 UI 和 API 中与作者、提交者字段并列展示；同时新增“Committer must match pusher”仓库规则，用于拦截提交者元数据与推送者已验证邮箱不匹配的推送，从而封堵提交身份伪造路径。该能力目前以有限公开预览形式面向 GitHub Enterprise 客户开放。
• 原贴提到：GitHub now durably records the authenticated user who pushed each commit
• 来源：github.blog

这是什么信号

这不是一个普通的界面小更新，而是 GitHub 在提交元数据的信任模型上做了一次结构性修补。过去提交记录里的 author（作者）和 committer（提交者）只是推送客户端填写的自由文本字符串，谁推送、用什么身份推送，和这两个字段没有任何强制绑定关系。GitHub 本来就在推送环节做认证，但认证结果没有被持久地落在那条提交上。现在，每条被推送进仓库的提交都会额外挂上一个持久的、经认证的推送者身份，并在 UI 和 API 里与作者、提交者字段并列展示。等于说：代码是谁写的仍然靠声明，代码是谁推进来的从此有据可查。

为什么重要

它改变的是审计的底层假设。如果提交者字段可以随意填写，那么基于这些字段建立的审查策略、代码溯源和事件调查都建立在一层可伪造的声明之上。原文给出的攻击路径很具体：攻击者只要拿下任意一个低权限账号，就能用这个账号推送出“看起来来自可信维护者”的提交，绕过审查策略，并在事后把审计线索搅乱——因为审计看到的名称和邮箱根本不是实际推送者。新增的仓库规则条件“Committer must match pusher”直接针对这条路径：当提交者元数据与经认证推送者的任何一个已验证邮箱都不匹配时，推送直接被拦下。这把“身份声明”和“身份事实”之间原本缺失的那一环补上了。

对谁有价值

三类人最直接受益。第一类是平台与安全工程团队：他们负责仓库规则集和供应链安全，此前只能靠签名、CODEOWNERS 或事后审查来间接防伪造，现在多了一道可在推送时执行的强约束。第二类是事件响应人员：排查可疑提交时，不必再在“未经验证的作者邮箱”上消耗时间，可以直接核对推送者身份，缩短取证链路。第三类是合规与审计相关角色：审计证据从“自述字段”变成“认证身份 + 自述字段”的双轨结构，追溯链条更站得住。

可以怎么行动

短期可以先做观测而不是直接阻断：在安全调查流程和告警规则中接入推送者字段，统计一段时间内“提交者与推送者不一致”的提交占比，据此判断误伤风险，再决定是否启用规则。中期针对自动化场景做规范：CI 机器人、镜像同步、批量脚本推送往往使用共享身份或本地 git 配置邮箱，这类推送最容易触发“提交者必须匹配推送者”的拦截，应提前把其提交邮箱统一为账号下的已验证邮箱。规则要放进规则集才能生效，建议先在少量仓库试运行，观察放行与拦截日志后再逐步扩大范围。此外，推送者归因与分支保护、审查策略是互补关系，前者约束“谁推的”，后者约束“能不能推”。

风险与限制

先看清边界。其一，推送者身份回答的是“谁执行了这次推送”，不等于“这段代码是谁写的”，它不替代代码签名，也不检测代码内容本身是否恶意。其二，规则依赖推送者的已验证邮箱，一旦组织内存在未验证邮箱、共享账号或历史遗留的本地 git 配置，合法的自动化推送也可能被误拦，需要先清理身份配置再强推。其三，该能力目前以有限公开预览形式面向 GitHub Enterprise 客户提供，且需要联系客户团队申请访问权限，非企业版用户短期内无法直接使用；即便是企业客户，也应把“预览”当作可能变动的能力来规划，而不是立刻写进硬性合规要求。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub 提交推送归因功能进入有限公测》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖