GitHub anunció el 12 de octubre de 2026 la vista previa pública limitada de la atribución de push para commits. La plataforma registra ahora, para cada commit subido, la identidad autenticada de la persona que realizó el push, independientemente de los campos autor y committer que declara el cliente Git. Una nueva condición de regla de repositorio permite exigir que el committer coincida con una dirección verificada de ese dispositivo autenticado.
El problema: metadatos de commit declarativos
Los campos autor y committer de un commit de Git son simples cadenas de texto que proporciona el cliente que realiza el push. Cualquier persona con acceso de escritura puede introducir en ellos el nombre y el correo que quiera. Una cuenta con pocos privilegios comprometida puede así producir commits que parecen firmados por un mantenedor de confianza, eludir políticas de revisión basadas en la identidad declarada y debilitar la fiabilidad de los rastros de auditoría ante un incidente.
Qué cambia la atribución de push
GitHub ya autentica cada operación de push. La novedad consiste en conservar esa identidad autenticada de forma permanente a nivel del propio commit, y no solo a nivel de la operación de push. Cada commit subido lleva ahora una identidad de quien lo subió, distinta de sus metadatos de autor y committer, visible allí donde aparece el historial de commits, tanto en la interfaz como a través de la API.
| Campo | Origen | Puede falsificarse |
|---|---|---|
| Autor | Declarado por el cliente Git | Sí |
| Committer | Declarado por el cliente Git | Sí |
| Quien sube (nuevo) | Sesión autenticada de GitHub | No |
Una regla de repositorio para la aplicación estricta
La vista previa introduce una nueva condición de regla, Committer must match pusher, que bloquea cualquier push cuya dirección de committer no coincida con ninguna dirección de correo verificada de la cuenta autenticada que realizó el push. Este mecanismo es lo que convierte la simple trazabilidad en una defensa real contra la suplantación de identidad de commits: la regla se añade a un conjunto de reglas existente en lugar de activarse de forma global.
La nueva condición de regla bloquea cualquier push cuya dirección de committer no coincida con ninguna dirección verificada de la cuenta autenticada que realizó el push.
La vista previa limitada está reservada a clientes de GitHub Enterprise. El acceso debe solicitarse al equipo de cuenta; el anuncio no menciona ningún otro requisito técnico.
Alcance y límites
La identidad de quien sube se añade junto a los campos existentes sin sustituirlos: un commit sigue mostrando un autor y un committer declarativos, a los que ahora se suma una identidad verificada. Para los equipos de seguridad, esto permite distinguir de un vistazo un commit cuyos metadatos declarados difieren de la identidad que realmente realizó la operación, sin esperar a una investigación manual de los registros de acceso. El problema de fondo coincide con el que ya planteó la apertura de la gestión de dist-tags de npm al trusted publishing: en ambos casos se trata de sustituir una declaración por una identidad verificada por la propia plataforma. En el flujo de trabajo diario, la función no cambia nada para los equipos que ya manejan varios worktrees de Git en paralelo: la identidad de quien sube se captura en el momento del push, sea cual sea el worktree o la rama de origen.
{
"commit": "a3f9c21",
"author": { "name": "Alice Martin", "email": "[email protected]" },
"committer": { "name": "Alice Martin", "email": "[email protected]" },
"pusher": { "login": "alice-m", "verified_email": "[email protected]" }
}Lo que hay que recordar
La atribución de push ataca un punto ciego conocido de Git: la facilidad con la que los campos autor y committer pueden falsificarse por cualquiera con acceso de escritura. Al conservar una identidad de quien sube autenticada y verificable de forma independiente, y al permitir exigirla mediante una regla de repositorio, GitHub da a los equipos de seguridad una señal fiable donde antes debían cruzar manualmente registros de acceso e historial de Git. La función, por ahora, sigue limitada a clientes Enterprise en vista previa.
Una función así habría evitado más de un sobresalto en auditorías de repositorios donde un commit firmado con el nombre de un mantenedor resultaba, en realidad, subido por un token de servicio mal acotado. Las firmas GPG resuelven parte del problema desde hace tiempo, pero siguen siendo opcionales y poco adoptadas fuera de los grandes proyectos de código abierto; una identidad de quien sube verificada por la propia plataforma, imposible de desactivar desde el cliente, cambia las cosas para los equipos que nunca llegaron a configurar la firma de commits. Queda por ver si GitHub extenderá la regla más allá del nivel Enterprise. — Simon Janvier
Para profundizar: la entrada oficial del changelog de GitHub sobre la atribución de push.
