Checklist de protección de ramas de GitHub
Puntúa las protecciones de rama y los rulesets que impiden que una sola credencial comprometida haga push, merge y borre sus huellas.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
La protección de ramas es lo que se interpone entre una credencial robada y tu rama de release. Este checklist interactivo recorre los controles de protección de ramas y de rulesets de GitHub que deciden si una sola credencial comprometida puede hacer push, fusionar y tapar sus huellas en tus ramas por defecto y de release: exigir un pull request y dos revisiones, comprobaciones de estado obligatorias, restringir quién puede hacer push, bloquear el force-push, no permitir que los administradores se salten las reglas, exigir commits firmados, restringir el origen de los workflows y gestionar las protecciones como un ruleset de la organización. Son quince controles en cuatro áreas (puertas de revisión, integridad y firma, restricciones de push y elusión, y controles de workflows y rulesets), cada uno con su gravedad, una justificación en lenguaje claro y una corrección concreta. Los controles que habrían roto un eslabón de la cadena de elusión al estilo LiteLLM de octubre de 2026 están marcados como «LiteLLM». Marca cada uno como aplicado, parcial o no configurado para obtener una puntuación de cobertura ponderada de 0 a 100, un desglose por área, las carencias priorizadas y un informe que puedes copiar o descargar. Funciona al 100 % en el cliente: no se lee ningún repositorio ni se sube nada, y los temas de los controles siguen la documentación de GitHub sobre ramas protegidas y rulesets. Es una herramienta Pro.
- Recorre los 15 controles de las cuatro áreas: revisiones, integridad y firma, restricciones de push y elusión, y workflows y rulesets.
- Marca cada uno como aplicado, parcial o no configurado.
- Fíjate en los controles marcados como «LiteLLM» y en la corrección concreta de cada carencia.
- Revisa la puntuación de 0 a 100 y las carencias priorizadas, y copia o descarga el informe.
Preguntas frecuentes
¿Qué ajuste anula con más frecuencia todos los demás?
Permitir que los administradores (o un actor con «bypass» en un ruleset) se salten las protecciones. Si los propietarios y administradores pueden saltarse las reglas, cada puerta de revisión, cada bloqueo de force-push y cada restricción de push pasa a ser opcional en cuanto se compromete una sola credencial de administrador. GitHub permite activar «Do not allow bypassing the above settings» o incluir a los administradores, y mantener vacía la lista de elusión del ruleset: ese es el control que hace reales todos los demás. Por eso mismo está marcado como LiteLLM en el checklist.
¿Por qué bloquear en concreto los force-push?
Un force-push reescribe el historial. Para encubrir un ataque a la cadena de suministro, el force-push es la forma en que un atacante hace que el commit malicioso parezca no haber existido nunca, o sustituye el registro de lo que pasó. Bloquear los force-push en las ramas protegidas (el comportamiento por defecto, que debes mantener, también para los administradores) significa que el historial de lo que se integró no puede sobrescribirse en silencio.
¿Reglas de protección de ramas o rulesets: cuál debo usar?
Los rulesets gestionados a nivel de organización son la opción más fuerte. Una regla clásica de protección de rama por repositorio la puede editar cualquiera con permisos de administrador en ese repositorio, así que un administrador de repositorio comprometido puede simplemente debilitarla. Un ruleset de organización lo gestionan los propietarios de la organización y se aplica a varios repositorios, de modo que un único administrador de repositorio no puede relajarlo en silencio. Define tus protecciones como un ruleset de organización siempre que puedas.
¿Cómo se relaciona con el incidente de LiteLLM?
En el compromiso de LiteLLM de octubre de 2026, según se informó públicamente, un atacante con un token de propietario de la organización pudo exfiltrar secretos de la CI, publicar una release compilada desde el origen de un fork, borrar registros de ejecuciones y hacer force-push para taparlo. Unas protecciones de rama y de rulesets sólidas (revisiones obligatorias, push restringido, sin elusión para administradores, force-push bloqueado, orígenes de workflows de confianza y rulesets gestionados por la organización) son justo los controles que convierten un «token de propietario» en «sigue bloqueado por las reglas» en lugar de «se acabó». Esta herramienta cita un incidente real y publicado como contexto y no está afiliada a LiteLLM ni a GitHub.
¿Una puntuación alta demuestra que mis ramas son seguras?
No. Puntúa los controles que dices aplicar; no lee ni verifica nada. Es una autoevaluación estructurada para encontrar carencias, no una auditoría. Confirma cada ajuste en el propio GitHub y vuelve a comprobarlo tras cualquier cambio.
¿Es gratis?
No, es una herramienta Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.