Secretos y variables protegidas del CI

En GitLab CI una variable se puede marcar como protegida: solo se entrega a los pipelines que corren en ramas protegidas o en etiquetas protegidas. Un pipeline que lanza alguien desde una rama cualquiera no la recibe. Es distinta de la marca de enmascarada, que solo oculta el valor en los registros de los trabajos; la propia documentación avisa de que enmascarar no es una garantía frente a quien controla el script.

En GitHub, el equivalente es el secreto de entorno: el trabajo no lo recibe hasta que se cumplen las reglas del entorno, como la aprobación de un revisor.

Una variable de producción que no está protegida la recibe cualquier pipeline del proyecto que la pida, también el de una rama de prueba que alguien con permiso de escritura acaba de crear. Cruza las columnas de protección y de entorno de las variables de GitLab.

Un secreto de GitHub guardado a nivel de repositorio lo puede usar cualquier flujo del repositorio, en cualquier rama. Uno guardado en un entorno con revisores solo llega al trabajo cuando alguien lo aprueba. Mira qué secreto lo usa el flujo que despliega a producción y dónde está guardado.

Una credencial que no se rota es una credencial que, si alguna vez se filtró, sigue valiendo. La política de Mirto Pagos pide rotar los secretos y las variables cada 180 días como máximo. Hoy es 4 de octubre de 2026, y esa fecha límite cae el 7 de abril de 2026: lo anterior está vencido.

Cuenta, entre los cuatro secretos de GitHub y las cuatro variables de GitLab, cuántos llevan más de 180 días sin rotarse.

Para el secreto de producción de GitHub no basta con rotarlo: habría que cambiar dónde vive. La documentación de GitHub dice que un trabajo no puede acceder a los secretos de un entorno hasta que un revisor lo aprueba. Y cuando el destino admite identidad federada, el token de identidad de corta vida evita guardar una clave larga.