El mapa de la canalización y sus permisos

Una canalización de integración y despliegue continuos es una serie de flujos que se disparan solos: cuando alguien abre una propuesta de cambio, cuando se une código a la rama principal, a una hora fija o cuando termina otro flujo. Cada flujo corre en una máquina llamada ejecutor y recibe credenciales para hacer su trabajo: un token para el repositorio, acceso al registro de imágenes, una identidad en la nube para desplegar.

El proyecto OWASP que reúne los riesgos de estas cadenas (su lista de diez riesgos de CI/CD) los agrupa en ideas que este módulo recorre: controles de flujo que dejan pasar un cambio sin revisar, identidades y permisos de más, dependencias de origen dudoso, credenciales mal guardadas y configuraciones inseguras de los sistemas. Para el evaluador la pregunta es siempre la misma: si alguien logra meter un cambio en este punto, ¿hasta dónde llega sin que otra persona lo vea?

Cada flujo debería declarar los permisos que necesita su token con la clave permissions, empezando por solo lectura y subiendo únicamente lo necesario. Un flujo que no la declara recibe el permiso por defecto del repositorio, y ese valor se fija en los ajustes, lejos del archivo que el equipo revisa.

Abre el laboratorio, lee el permiso por defecto en ajustes/ y recorre los cinco flujos de flujos/. Busca el que no declara nada.

El mapa de una canalización se dibuja siguiendo los disparadores: qué evento arranca cada flujo y qué produce. Un flujo que se dispara al terminar otro hereda la confianza del primero: si el primero construyó algo que nadie revisó, el segundo lo despliega igual.

Lee los disparadores (on:) de los flujos y encuentra el que fabrica lo que el flujo de despliegue pone en producción.

Una cadena automática no es un hallazgo por sí misma: desplegar varias veces al día es una práctica sana si alguna persona distinta del autor revisa cada cambio antes de que entre a la rama que se despliega, o si el entorno de producción exige una aprobación. El hallazgo aparece cuando ningún punto del camino pide una segunda mirada.

Las entrevistas explican las decisiones, pero no sustituyen la evidencia. Que el equipo diga que revisa el código «cuando hay tiempo» describe una costumbre; la configuración exportada describe lo que el sistema impide y lo que no. En el informe se cita la configuración, y la entrevista sirve para entender por qué se llegó ahí y qué corrección es aceptable para el negocio.