GitHub hat am 12. Oktober 2026 die begrenzte Public Preview der Push-Attribution für Commits angekündigt. Die Plattform erfasst nun für jeden gepushten Commit die authentifizierte Identität der Person, die den Push durchgeführt hat — unabhängig von den Feldern Autor und Committer, die der Git-Client angibt. Eine neue Regelbedingung für Repositories erlaubt es, zu verlangen, dass der Committer mit einer verifizierten Adresse dieses authentifizierten Pushers übereinstimmt.
Das Problem: deklarative Commit-Metadaten
Die Felder Autor und Committer eines Git-Commits sind reiner Text, den der pushende Client angibt. Jede Person mit Schreibzugriff kann dort beliebige Namen und E-Mail-Adressen eintragen. Ein kompromittiertes Konto mit geringen Rechten kann so Commits erzeugen, die wie von einer vertrauenswürdigen Maintainerin stammen, Review-Richtlinien umgehen, die auf der deklarierten Identität beruhen, und die Verlässlichkeit von Audit-Spuren im Ernstfall untergraben.
Was die Push-Attribution ändert
GitHub authentifiziert bereits jeden Push. Neu ist, diese authentifizierte Identität dauerhaft auf Ebene des einzelnen Commits zu speichern, statt nur auf Ebene des Push-Vorgangs. Jeder gepushte Commit trägt nun eine Pusher-Identität, die unabhängig von seinen Autor- und Committer-Metadaten ist und überall sichtbar wird, wo Commit-Verlauf angezeigt wird — in der Oberfläche wie über die API.
| Feld | Quelle | Fälschbar |
|---|---|---|
| Autor | Vom Git-Client angegeben | Ja |
| Committer | Vom Git-Client angegeben | Ja |
| Pusher (neu) | Authentifizierte GitHub-Sitzung | Nein |
Eine Repository-Regel für die strikte Durchsetzung
Die Preview führt eine neue Regelbedingung ein, Committer must match pusher, die jeden Push blockiert, bei dem die Committer-Adresse mit keiner verifizierten E-Mail-Adresse des authentifizierten, pushenden Kontos übereinstimmt. Dieser Mechanismus macht aus reiner Nachvollziehbarkeit einen echten Schutz gegen das Fälschen von Commit-Identitäten: Die Regel wird einem bestehenden Regelwerk (Ruleset) hinzugefügt, statt global aktiviert zu werden.
Die neue Regelbedingung blockiert jeden Push, bei dem die Committer-Adresse mit keiner verifizierten Adresse des authentifizierten Pushers übereinstimmt.
Die begrenzte Preview ist GitHub-Enterprise-Kunden vorbehalten. Der Zugang muss beim zuständigen Account-Team angefragt werden; die Ankündigung nennt keine weiteren technischen Voraussetzungen.
Umfang und Grenzen
Die Pusher-Identität ergänzt die bestehenden Felder, statt sie zu ersetzen: Ein Commit zeigt weiterhin einen deklarierten Autor und Committer, dem nun eine verifizierte Identität zur Seite steht. Für Sicherheitsteams lässt sich so auf einen Blick erkennen, wenn die deklarierten Metadaten eines Commits von der tatsächlich ausführenden Identität abweichen, ohne auf einen manuellen Abgleich von Zugriffsprotokollen warten zu müssen. Das zugrunde liegende Problem ähnelt dem, das bereits die Öffnung der npm-Dist-Tag-Verwaltung für Trusted Publishing aufgeworfen hat: In beiden Fällen tritt eine von der Plattform selbst verifizierte Identität an die Stelle einer blossen Behauptung. Am täglichen Arbeitsablauf ändert die Funktion nichts für Teams, die bereits mehrere parallele Git-Worktrees nutzen: Die Pusher-Identität wird beim Push erfasst, unabhängig davon, aus welchem Worktree oder Branch er stammt.
{
"commit": "a3f9c21",
"author": { "name": "Alice Martin", "email": "[email protected]" },
"committer": { "name": "Alice Martin", "email": "[email protected]" },
"pusher": { "login": "alice-m", "verified_email": "[email protected]" }
}Was man sich merken sollte
Die Push-Attribution adressiert einen bekannten blinden Fleck in Git: wie leicht sich die Felder Autor und Committer von jedem mit Schreibzugriff fälschen lassen. Indem GitHub eine unabhängig verifizierbare, authentifizierte Pusher-Identität bewahrt und Teams erlaubt, sie über eine Repository-Regel durchzusetzen, erhält die Sicherheitsabteilung ein verlässliches Signal, wo zuvor nur der manuelle Abgleich von Zugriffsprotokollen und Git-Historie half. Die Funktion bleibt vorerst auf Enterprise-Kunden in der Preview beschränkt.
So eine Funktion hätte manchem kalten Schweiss bei Repository-Audits vorgebeugt, wenn sich ein mit dem Namen eines Maintainers signierter Commit als von einem schlecht abgegrenzten Service-Token gepusht entpuppte. GPG-Signaturen lösen einen Teil des Problems schon lange, bleiben aber optional und sind ausserhalb grosser Open-Source-Projekte kaum verbreitet; eine von der Plattform selbst verifizierte Pusher-Identität, die sich client-seitig nicht abschalten lässt, ändert die Ausgangslage für Teams, die nie dazu kamen, Commit-Signaturen einzurichten. Ob GitHub die Regel über die Enterprise-Stufe hinaus ausweitet, bleibt abzuwarten. — Simon Janvier
Zum Weiterlesen: der offizielle GitHub-Changelog-Eintrag zur Push-Attribution.
