El badge Verified de GitHub se puede falsificar: qué implica

Sí: el badge verde "Verified" de GitHub certifica que una firma criptográfica es matemáticamente válida y que la clave está vinculada a una cuenta, pero no certifica que esa persona escribiera o revisara el código, ni que la cadena de commits detrás no se haya recompuesto en algún punto. Es una prueba de firma, no una prueba de autoría o revisión humana — y esa diferencia es exactamente lo que un atacante o un proceso mal configurado puede explotar sin romper ninguna criptografía.

El contenido que se firma (y lo que se queda fuera)

Cuando ejecutas git commit -S, la firma cubre el objeto commit completo: el hash del árbol de ficheros, el hash del commit padre, el nombre y email del autor/committer, y el mensaje. Esa firma demuestra que quien tenía la clave privada en ese momento produjo exactamente ese conjunto de bytes. Lo que no demuestra es que el email incluido pertenece a la persona que aparenta ser, que la clave no ha sido comprometida, ni que el árbol firmado sea "el código correcto" en algún sentido humano. GitHub añade encima una comprobación mecánica: si la clave pública está asociada a una cuenta y el email del commit coincide con un email verificado de esa cuenta, pinta el badge verde. Si no cuadra, marca "Unverified" — el criterio es puramente técnico, no editorial.

La cadena de hashes no es tan inmutable como parece

Git encadena su historial con hashes SHA-1: cada commit incluye el hash del anterior, así que alterar cualquier byte de un commit antiguo debería romper todos los hashes posteriores. En 2017, investigadores de Google y CWI Amsterdam publicaron "SHAttered" (Google Security Blog, 2017), la primera colisión SHA-1 práctica documentada, demostrando que dos contenidos distintos pueden producir el mismo hash con suficiente cómputo dirigido. Git respondió ese mismo año incorporando detección de colisiones reforzada, y el ecosistema lleva desde entonces migrando de forma gradual hacia SHA-256. Eso es la "malleability" de la cadena de hashes: la garantía de integridad no es absoluta, es computacionalmente cara de romper hoy, que es una frase muy distinta de "imposible". Para una PYME esto no es la amenaza más probable — una colisión SHA-1 dirigida sigue siendo carísima — pero es la base técnica que casi ningún artículo sobre el tema explica bien.

Aquí está el mecanismo explotable con recursos normales que casi nadie menciona: cuando mergeas un pull request desde la interfaz web de GitHub, el commit de merge resultante lo firma el propio bot de GitHub ("web-flow"), no los autores originales de los commits que contiene. Ese commit de merge aparece como Verified porque GitHub firmó ese objeto concreto, no porque cada commit individual dentro del PR estuviera firmado por quien dice haberlo escrito. Un colaborador con permisos de escritura puede abrir un PR con commits sin firmar, atribuidos a otro autor, y tras el merge el badge verde queda en main sin que nadie haya verificado la identidad real de quien escribió el código. "Todo en main tiene badge verde" no equivale a "todo en main fue firmado por quien dice haberlo firmado" — son afirmaciones distintas que el propio diseño de GitHub invita a confundir.

La cadena de suministro de software no es solo qué librerías instaláis: incluye qué commits confía tu empresa como base para desplegar a producción, qué GitHub Actions ejecutáis con permisos de escritura, y qué badge usáis como criterio de aprobación en el pipeline. Si un pipeline bloquea merges "no verificados" pero acepta cualquier cosa con badge verde, un atacante que consiga colaborar en el repo — vía cuenta comprometida, contratista externo, o ingeniería social — puede introducir código con badge verde sin que nadie lo firmara personalmente. Este es exactamente el patrón detrás de buena parte del daño en incidentes de cadena de suministro recientes: no hace falta romper criptografía, basta con explotar la diferencia entre lo que el sistema certifica y lo que el equipo asume que certifica.

No todas las empresas necesitan una plataforma de SCA de pago ni firma de artefactos nivel SLSA 3. Muchas PYMEs que auditamos ni siquiera tienen activada la protección de rama básica en GitHub, así que ese es el primer euro bien gastado, no perseguir el badge Verified. La criptografía perfecta no compensa un proceso de revisión que no existe.

• Activa branch protection en main/master exigiendo al menos una revisión humana aprobada, no solo el badge verde
• Configura "Require signed commits" en las ramas protegidas, no solo confíes en el badge visual del merge
• Audita si vuestros commits recientes en main están firmados por personas concretas o por el bot web-flow de merges desde la interfaz
• Revisa qué GitHub Actions de terceros tienen permisos de escritura y si están fijadas a un commit hash concreto, no a una etiqueta mutable
• Documentad explícitamente en vuestro runbook de seguridad qué garantiza (y qué no) el badge Verified antes de automatizar despliegues desde main

La respuesta honesta depende del tamaño del equipo y de qué tan crítico es lo que desplegáis desde ese repositorio. Si sois un equipo pequeño con permisos de escritura conocidos y sin colaboradores externos, el riesgo de suplantación vía badge es bajo — vuestro riesgo real probablemente está en gestión de secretos o en dependencias sin revisar, no en la cadena de hashes de git. Si en cambio tenéis contratistas externos o Actions de terceros con permisos amplios sobre un repositorio que alimenta producción, la brecha entre "verificado" y "revisado por una persona" deja de ser teórica y pasa a ser una superficie de ataque razonable de cerrar esta semana. En las auditorías que hacemos a clientes españoles de este tamaño encontramos con más frecuencia protecciones de rama mal configuradas que ataques sofisticados contra la propia firma — empezar por lo aburrido suele dar más retorno de seguridad por euro invertido que perseguir el vector más exótico.