GitHub a annoncé le 12 octobre 2026 l’arrivée en avant-première limitée de l’attribution de push pour les commits. La plateforme enregistre désormais, pour chaque commit poussé, l’identité authentifiée de la personne qui a effectué le push, indépendamment des champs auteur et committeur déclarés par le client Git. Une nouvelle condition de règle de dépôt permet d’exiger que le committeur corresponde à une adresse vérifiée de ce périphérique authentifié.
Le problème : des métadonnées de commit déclaratives
Les champs auteur et committeur d’un commit Git sont de simples chaînes de texte fournies par le client qui pousse le code. Toute personne disposant d’un accès en écriture peut y inscrire le nom et l’adresse email de son choix. Un compte à faibles privilèges compromis peut ainsi produire des commits qui semblent signés par un mainteneur de confiance, contourner certaines politiques de revue basées sur l’identité déclarée, et fragiliser la fiabilité des pistes d’audit en cas d’incident.
Ce que change l’attribution de push
GitHub authentifie déjà chaque opération de push. La nouveauté consiste à conserver cette identité authentifiée, de manière permanente, au niveau du commit lui-même plutôt qu’au niveau de la seule opération de push. Chaque commit poussé porte ainsi une identité de pousseur distincte de ses métadonnées d’auteur et de committeur, visible partout où l’historique de commits apparaît dans l’interface et via l’API.
| Champ | Source | Peut être falsifié |
|---|---|---|
| Auteur | Déclaré par le client Git | Oui |
| Committeur | Déclaré par le client Git | Oui |
| Pousseur (nouveau) | Session authentifiée GitHub | Non |
Une règle de dépôt pour l’application stricte
L’avant-première introduit une condition de règle de dépôt, Committer must match pusher, qui bloque tout push dont l’adresse du committeur ne correspond à aucune adresse email vérifiée du compte authentifié ayant réalisé le push. C’est ce mécanisme qui transforme une simple traçabilité en véritable défense contre l’usurpation d’identité de commit : la règle s’ajoute à un jeu de règles (ruleset) existant plutôt que de s’activer globalement.
La nouvelle condition de règle bloque tout push dont l’adresse du committeur ne correspond à aucune adresse vérifiée du compte authentifié.
L’avant-première limitée est réservée aux clients GitHub Enterprise. L’accès se demande auprès de l’équipe de compte GitHub ; aucun autre prérequis technique n’est mentionné dans l’annonce.
Portée et limites
L’identité de pousseur s’ajoute aux champs existants sans les remplacer : un commit continue d’afficher un auteur et un committeur déclaratifs, auxquels s’ajoute désormais une identité vérifiée. Pour les équipes de sécurité, cela permet de distinguer en un coup d’œil un commit dont les métadonnées déclarées divergent de l’identité réelle ayant réalisé l’opération, sans attendre une investigation manuelle sur les journaux d’accès. L’enjeu rejoint celui de la chaîne d’approvisionnement logicielle déjà posé par l’ouverture du trusted publishing sur npm : dans les deux cas, il s’agit de remplacer une déclaration par une identité vérifiée par la plateforme. Côté flux de travail quotidien, la fonctionnalité ne change rien pour les équipes qui manipulent déjà plusieurs arbres de travail Git en parallèle : l’identité de pousseur est capturée au moment du push, quel que soit le worktree ou la branche d’origine.
{
"commit": "a3f9c21",
"author": { "name": "Alice Martin", "email": "[email protected]" },
"committer": { "name": "Alice Martin", "email": "[email protected]" },
"pusher": { "login": "alice-m", "verified_email": "[email protected]" }
}Ce qu’il faut retenir
L’attribution de push s’attaque à un angle mort connu de Git : la facilité avec laquelle les champs auteur et committeur peuvent être falsifiés par quiconque dispose d’un accès en écriture. En conservant une identité de pousseur authentifiée et vérifiable indépendamment, et en permettant de la rendre obligatoire via une règle de dépôt, GitHub donne aux équipes de sécurité un signal fiable là où elles devaient jusqu’ici croiser manuellement journaux d’accès et historique Git. La fonctionnalité reste pour l’instant réservée aux clients Enterprise en avant-première.
Ce genre de fonctionnalité aurait évité pas mal de sueurs froides lors d’audits de dépôts où un commit signé d’un nom de mainteneur s’avérait en réalité poussé par un jeton de service mal cloisonné. Les signatures GPG règlent une partie du problème depuis longtemps, mais elles restent optionnelles et mal adoptées en dehors des gros projets open source ; une identité de pousseur vérifiée par la plateforme elle-même, impossible à désactiver côté client, change la donne pour les équipes qui n’ont jamais pris le temps de mettre en place la signature de commits. Reste à voir si GitHub étendra la règle au-delà du périmètre Enterprise. — Simon Janvier
Pour aller plus loin : l’entrée officielle du changelog GitHub sur l’attribution de push.
