Proteccion de Rama Faltante

Sin proteccion de rama en main/produccion, cualquier desarrollador (o cuenta comprometida) puede pushear directamente, hacer force-push con cambios destructivos o mergear sin revision de codigo, saltandose todas las validaciones de calidad y seguridad.

Cómo Funciona

Las reglas de proteccion de rama son el mecanismo de GitHub para hacer cumplir requisitos de revision y CI antes de que el codigo llegue a ramas importantes. Sin ellas, no hay nada que impida a un desarrollador pushear directamente a main, hacer force-push para reescribir el historial, mergear un PR sin revision o saltarse checks de CI fallidos. Si la cuenta de un desarrollador es comprometida via robo de credenciales o ingenieria social, el atacante tiene acceso sin restricciones para modificar el codigo de produccion. Incluso sin intencion maliciosa, la falta de proteccion de rama significa que force-pushes accidentales, codigo sin testear y cambios sin revisar pueden llegar a produccion. Esto es especialmente peligroso cuando CI/CD despliega automaticamente desde main.

Código Vulnerable

# BAD: no branch protection configured (shown as Terraform for GitHub)
resource "github_repository" "app" {
  name       = "production-app"
  visibility = "private"
  # No branch protection resource defined
  # Anyone can push directly to main
  # No required reviews, no status checks
  # Force push is allowed
}
# Result: developers push directly to main
# git push origin main  -- works without review
# git push --force origin main  -- rewrites history

Código Seguro

# GOOD: branch protection with required reviews and status checks
resource "github_branch_protection" "main" {
  repository_id  = github_repository.app.node_id
  pattern        = "main"
  enforce_admins = true

  required_pull_request_reviews {
    required_approving_review_count = 1
    dismiss_stale_reviews           = true
    require_code_owner_reviews      = true
  }

  required_status_checks {
    strict   = true  # branch must be up-to-date before merging
    contexts = ["ci/test", "ci/lint", "security/scan"]
  }

  restrict_pushes {
    blocks_creations = true
  }

  allows_force_pushes  = false
  allows_deletions     = false
}

Ejemplo Real

En el compromiso del servidor Git de PHP en 2020, los atacantes pushearon commits maliciosos directamente a la rama main del repositorio php-src, agregando un backdoor al codigo fuente de PHP. Los commits fueron disfrazados como correcciones de errores tipograficos. Este incidente llevo a PHP a migrar a GitHub e implementar reglas de proteccion de rama requiriendo revisiones de PR. Demostro como una sola rama sin proteccion puede permitir ataques a la cadena de suministro afectando millones de usuarios downstream.

Cómo Prevenirlo

Habilita proteccion de rama en todas las ramas main/produccion requiriendo al menos una revision de pull request antes de mergear
Requiere que los status checks pasen (tests CI, linting, escaneos de seguridad) antes de permitir merges
Deshabilita force pushes y eliminacion de ramas en ramas protegidas para prevenir reescritura del historial
Habilita 'enforce admins' para que incluso los administradores del repositorio deban seguir las reglas de proteccion

Tecnologías Afectadas

GitHub ActionsNode.jsPythonDocker

Data Hogo detecta esta vulnerabilidad automáticamente.

Escanea Tu Repo Gratis

Vulnerabilidades Relacionadas

GitHub Actions Sin Fijar a SHA

high

Usar GitHub Actions referenciados por tags mutables como @main o @v3 en lugar de SHAs de commit completos significa que una action comprometida o secuestrada puede inyectar codigo malicioso en tu pipeline CI sin ningun cambio en tu archivo workflow.

CWE-1395OWASP A08:2021

Inyeccion de Script en GitHub Actions

critical

Usar datos de eventos no confiables como github.event.issue.title directamente dentro de bloques run: permite a los atacantes inyectar comandos shell arbitrarios en tu pipeline CI creando titulos de issues, cuerpos de PR o mensajes de commit maliciosos.

CWE-94OWASP A03:2021

Secretos Filtrados en Logs de CI

high

Imprimir o hacer echo de variables de entorno que contienen secretos en scripts de CI los expone en los logs de build, que frecuentemente son accesibles para todos los colaboradores del repositorio y a veces visibles publicamente en proyectos open-source.

CWE-532OWASP A09:2021

Riesgos de Runners Self-Hosted

high

Usar runners self-hosted de GitHub Actions con pull_request_target o workflows de forks publicos permite que codigo no confiable de contribuidores externos se ejecute en tu infraestructura con acceso a secrets, estado persistido y la red del host.

CWE-94OWASP A08:2021