- GitHub is previewing push attribution for Enterprise customers. It records the authenticated account that pushed each commit. Author and committer fields can be set freely by anyone with write access.
- This matters because forged names can evade review policies and confuse audit trails. GitHub adds a rule that blocks pushes whose committer does not match the pusher.
- The preview is limited to GitHub Enterprise customers. Ask your account team for access and test the rule on one repository first.
The name on a software commit does not prove who made it. It works like the return address on an envelope. The sender writes it. GitHub's new push attribution, announced on October 12, adds the postmark. It records which signed-in account actually sent each change.
How a commit can lie
Every commit carries an author field and a committer field. The pushing client supplies both as plain text. GitHub's announcement says anyone with write access can set them to any name and email.
So anyone who can push to a repository can put any name and email on their commits. GitHub spells out the danger. Say an attacker takes over an account with little power. That account could still push commits that look like a trusted maintainer wrote them.
GitHub says such commits can slip past review policies. They can also muddy the audit trail.
What GitHub changed
GitHub already checked who was signing in to push. What it did not do was keep that fact attached to each commit. Now it keeps a lasting record of the authenticated user who pushed every commit. The UI and the API show this pusher identity next to the author and committer fields.
GitHub also added an option to enforce the match. It is a repository rule condition called Committer must match pusher. The rule blocks a push when the committer details do not match a verified email of the account that pushed. In GitHub's telling, this closes one path to faked commit identities. Teams turn it on by adding the rule to a ruleset.
The idea: an audit trail should rest on facts, not claims
Many organisations treat commit history as a record of who did what. Until now, part of that record was self-reported. A reviewer reading the author line was reading what the sender chose to write.
The lesson here is that identity in a record should come from the system, not from the person being recorded. GitHub's advice points the same way. It says to use the pusher identity to spot-check suspicious activity, rather than rely on unverified metadata.
This matters most after something has gone wrong. A team asks which account made a change. A forged name is worse than a missing one. It sends the investigation to the wrong person.
What the announcement does not say
This is a limited public preview. It is open to GitHub Enterprise customers. Interested teams must ask their account team for access.
The announcement does not say whether older commits carry a pusher identity. It does not explain how shared automation accounts are treated. The new rule, as described, compares the committer field to the pusher. GitHub does not say it checks the author field.
These are gaps in the announcement, not flaws in the feature. They are the first things to test.
Questions to put to your team
First, are we on GitHub Enterprise, and has anyone asked for preview access? Second, how many accounts can write to our repositories? Faking a name takes write access, so that number is the exposure.
Third, do our incident runbooks start from the author line or the pusher identity? Fourth, before enforcing Committer must match pusher widely, try it on one repository. Check that legitimate workflows, including automated ones, push with an email verified for the pushing account.
A name on a commit is still a claim. The pusher identity is the postmark, and audits should start there.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub.
