Tus GitHub Actions tienen demasiados permisos y no lo sabes 🤯
La mayoría de los equipos configuran sus flujos de CI/CD para que 'simplemente funcionen'. El problema es que, en el proceso, dejan la puerta abierta. Cuando un workflow tiene más permisos de los necesarios, un simple j
Artículo
Una lectura sobre tecnología y sistemas digitales, escrita para ir al punto y dejar claras las ideas principales.
Tema principal
ciberseguridad
Fuente
dev.to
Puntos clave
- La mayoría de los equipos configuran sus flujos de CI/CD para que 'simplemente funcionen'. El problema es que, en el proceso, dejan la puerta abierta.
- Cuando un workflow tiene más permisos de los necesarios, un simple job de build se convierte en una autopista para que un atacante modifique el repositorio, robe tokens o comprometa el despliegue.
- El error es tratar el pipeline como una entidad única y confiable, en lugar de tratar cada job como un límite de seguridad independiente.
- Para reducir el 'blast radius', aplico siempre esta estrategia de Privilegio Mínimo:
Bloque 1
La mayoría de los equipos configuran sus flujos de CI/CD para que 'simplemente funcionen'. El problema es que, en el proceso, dejan la puerta abierta.
Cuando un workflow tiene más permisos de los necesarios, un simple job de build se convierte en una autopista para que un atacante modifique el repositorio, robe tokens o comprometa el despliegue.
Bloque 2
El error es tratar el pipeline como una entidad única y confiable, en lugar de tratar cada job como un límite de seguridad independiente.
Para reducir el 'blast radius', aplico siempre esta estrategia de Privilegio Mínimo:
Bloque 3
• Establecer un baseline restrictivo: Configurar 'permissions: contents: read' a nivel de workflow para que nada escriba por defecto. • Segmentación de permisos: Otorgar acceso de escritura (write) únicamente al job específico que lo requiera (ej. el de release), no a todo el pipeline. • Adiós a los secretos estáticos: Implementar OIDC (OpenID Connect) para accesos a AWS o Azure, eliminando claves de larga duración en los secrets. • Verificación por fallo: No basta con que el pipeline pase; hay que intentar ejecutar una acción prohibida y confirmar que el sistema la bloquee.
La seguridad en DevSecOps no se trata de bloquear la velocidad, sino de hacer que el acceso sea explícito y auditable.
Bloque 4
¿Cómo están gestionando los permisos de sus pipelines para evitar el 'blast radius' en producción?