Dev News Daily ENDE

GitHub speichert, wer jeden Commit gepusht hat, und kann Committer-Fälschung blockieren

GitHub hat am 12. Oktober angekündigt, den authentifizierten Nutzer, der einen Commit gepusht hat, dauerhaft zu speichern und diese Pusher-Identität in Weboberfläche und API neben den bisherigen Feldern Autor und Committer anzuzeigen. Die Funktion ist als begrenzte öffentliche Vorschau für GitHub-Enterprise-Kunden verfügbar; die Teilnahme läuft über das jeweilige Account-Team.

Das Problem dahinter. In Git sind Autor und Committer eines Commits einfache Zeichenketten, die der erzeugende Client einträgt. GitHubs Changelog nennt die Folge offen: Jeder mit Schreibrechten kann diese Felder auf beliebige Namen und Adressen setzen. Ein Angreifer, der ein Konto mit geringen Rechten übernimmt, kann so Commits pushen, die scheinbar von einem vertrauenswürdigen Maintainer stammen – das kann Review-Regeln umgehen und Audit-Spuren verwischen. Den Push selbst hat GitHub immer authentifiziert; diese Identität wurde bisher aber nicht mit jedem Commit festgehalten.

Was sich ändert. Jeder in ein Repository gepushte Commit trägt jetzt eine Pusher-Identität, unabhängig davon, was Autor- und Committer-Metadaten behaupten. Zusätzlich blockiert die neue Regelbedingung „Committer must match pusher“ Pushes, bei denen die Committer-Angabe zu keiner verifizierten E-Mail-Adresse des authentifizierten Pushers passt. GitHub beschreibt das als Schließen eines Weges zur Fälschung von Commit-Identitäten.

GitHub speichert, wer jeden Commit gepusht hat, und kann Committer-Fälschung blockieren
GitHub speichert, wer jeden Commit gepusht hat, und kann Committer-Fälschung blockieren — Dev News Daily

Was sich nicht ändert. Autor und Pusher dürfen weiter auseinanderfallen – normal, wenn jemand die Arbeit eines Kollegen oder einen umgeschriebenen Branch pusht. Die neue Regel prüft das Committer-Feld gegen die verifizierten Adressen des Pushers; Teams, die für andere pushen oder Bots und Automatisierungskonten nutzen, sollten diese Abläufe prüfen, bevor sie die Regel überall einschalten.

Warum es für Audits zählt. Für die Vorfallsbearbeitung ist weniger die Sperre als die Aufzeichnung wertvoll: Wird ein schädlicher Commit gefunden, ist die Frage „welches Konto hat ihn tatsächlich hierher gebracht“ jetzt direkt am Commit beantwortet, statt aus Audit-Logs rekonstruiert zu werden.

Quelle: GitHub Changelog, „Push attribution for commits in limited public preview“ — https://github.blog/changelog/2026-10-12-push-attribution-public-preview