La fuga de Secretos no siempre se debe a código malicioso o bibliotecas vulnerables. A veces, depende de cómo gestionamos Secretos durante las ejecuciones de CI, y CVE-2025-30066 es un ejemplo clásico de cómo esto puede salir mal. La acción de GitHub tj-actions/changed-files, ampliamente utilizada para detectar archivos modificados en pull requests, se convirtió en un canal silencioso para la filtración de Secreto. Esto es lo que pasó y cómo puedes proteger tu privacidad. CI/CD Secretos pipeline.
¿Qué sucedió en CVE‑2025‑30066?
A mediados de marzo de 2025, tj‑actions/changed‑files se vio comprometido. El atacante reescribió las etiquetas de versiones existentes (hasta v45.0.7) para apuntar a una versión maliciosa. commitEsto alteró el comportamiento de la Acción sin que los desarrolladores lo notaran; no se lanzó ninguna versión nueva, solo una manipulación invisible de las etiquetas.
La carga útil era sencilla pero peligrosa: extraía un script remoto de Python codificado en Base64 que escaneaba la memoria del ejecutor en busca de credenciales, volcándolas en registros o exfiltrándolas. No se trataba de una falla de código lógica en los archivos tj-actions/changed-files; era un abuso de cómo se pueden producir fugas de Secretos en los flujos de trabajo de CI que utilizan esa acción reutilizable. La CVE-2025-30066 no se relacionaba con desbordamientos de búfer, sino con un fallo de diseño de CI que permitía la fuga de Secretos.
Impacto: cualquier repositorio que utilice las versiones afectadas de tj‑actions/changed‑files corría el riesgo de sufrir una fuga de Secreto, especialmente si se manejaban tokens o archivos confidenciales de forma insegura en patrones de archivos o salidas de CI.
Por qué esto afecta a los flujos de trabajo que dependen de acciones reutilizables
Flujos de trabajo de DevSecOps Depende en gran medida de tj‑actions/changed‑files para:
- Automatiza los procesos con tecnología. pull request cheques
- Identificar archivos modificados en rutas específicas
- Evite trabajos de CI redundantes
Pero estos flujos de trabajo a menudo pasan por alto un aspecto: cómo los patrones glob pueden incluir datos confidenciales. Los desarrolladores asumen que tj-actions/changed-files se comporta de forma segura por defecto. Sin embargo, si se usan patrones glob configuraciones/** y los secretos se almacenan en configuraciones/Secretos.envAcabas de agregar un archivo Secreto a las salidas o registros de CI. No es un error de la acción; es un CI/CD Fallo de diseño que provoca fugas de Secreto. CVE‑2025‑30066 es un claro ejemplo de ello.
Cómo se produjo la fuga de Secreto (análisis de vulnerabilidades)
Analicemos el error principal detrás de CVE-2025-30066:
- Patrones globulosos como **/*.env archivos Secreto coincidentes sin querer
- tj‑actions/changed‑files trató esos Secretos como archivos modificados
- Los secretos terminaron en salidas de pasos, registros o trabajos posteriores
Esto ocurrió porque los Secretos se almacenaban en rutas con control de versiones (mala idea) y la configuración de CI no los excluía explícitamente de la gestión global (también mala). Por lo tanto, no se trata de un error de código, sino de una mala higiene en el diseño de CI que causa fugas de Secretos con las salidas de tj-actions/changed-files.
Ruta de explotación práctica: del trabajo de CI a la exposición de credenciales
Ejemplo de configuración de CI que provocó una fuga de Secreto a través de tj-actions/changed-files:
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Check changed files
id: changed
uses: tj‑actions/changed‑files@v45
with:
files: configs/**
If configuraciones/Secretos.env cambiado:
- Fue marcado por tj‑actions/changed‑files
- Se incluyó en pasos.salidas.cambiadas.todos_los_archivos_cambiados
- Los pasos posteriores lo registraron o lo pasaron a scripts, filtrando Secretos.
Esta fuga se produjo porque la lógica de CI trataba los Secretos como archivos normales. Ahí es donde comienza la fuga de Secretos, no por un desbordamiento de búfer, sino por el uso indebido de tj-actions/changed-files en un diseño de CI defectuoso.
La propagación ocurre con salidas como:
yaml
‑ name: Use changed file list
run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}"
If Secretos.env está en esa lista, su nombre de archivo y posiblemente su contenido podrían aparecer en los registros de compilación. Incluso lógica condicional como:
yaml
if: contains(steps.changed.outputs.all_changed_files, 'Secretos.env')
Puede exponer artefactos sensibles. Esto es un CI/CD Falla de diseño que permitió la fuga de Secreto, no una falla en el código de Acción.
Cómo utilizar flujos de trabajo reutilizables de forma segura y evitar fugas
No es necesario abandonar tj-actions/changed-files. Debes usar acciones reutilizables priorizando los secretos:
Mejores prácticas para el manejo de secretos
- No controle versiones de Secretos, nunca
- Evite patrones glob que coincidan con rutas sensibles
- Utilice Secretos basados en el entorno (GITHUB_ENV, bóvedas, GitHub Secretos)
CI/CD Configuration Guardrails
- Siempre fije las acciones a SHA inmutables, no a etiquetas (nunca use @ V45)
- Tratar la salida de tj-actions/changed-files como contaminada, desinfectarla o filtrarla
- Establecer salidas solo si están desinfectadas
⚠️ Ejemplo inseguro:
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Detect all changes
id: changed
uses: tj‑actions/changed‑files@v45
with:
files: '**/*' # ⚠️ This glob includes Secretos.env, which may leak credentials
Lo anterior es exactamente el mal uso detrás de la filtración de Secreto y CVE-2025-30066.
Alternativa segura:
yaml
jobs:
detect_changes:
runs‑on: ubuntu‑latest
steps:
‑ uses: actions/checkout@v3
‑ name: Detect non‑sensitive file changes
id: changed
uses: tj‑actions/changed‑files@<SHA> # pinned to SHA
with:
files: 'src/**'
files‑ignore: '**/Secretos.env' # ⚠️ Excludes Secreto file
Al hacer esto, evitarás la CI/CD Error de diseño que provoca fugas de Secreto a través de tj-actions/changed-files.
Adicionalmente:
- Deshabilitar o restringir el registro donde podrían aparecer los Secretos
- Utilice las funciones de enmascaramiento de Secreto de GitHub
- Limitar el acceso a los registros de compilación y artefactos
Lista de verificación rápida para el uso seguro de CI de Secretos
| Mejores Prácticas |
|---|
| No guarde secretos en archivos con control de versiones |
| Utilice bóvedas o GitHub Secretos para las credenciales |
| Fije siempre tj‑actions/changed‑files a SHA inmutables |
| Filtrar o desinfectar las salidas de tj-actions/changed-files |
| Nunca incluya rutas Secreto en patrones glob |
| Enmascarar o restringir registros que puedan exponer datos confidenciales |
| Auditar configuraciones de CI heredadas con frecuencia |
El rol de Xygeni: Aplicación de secretos de CI a gran escala
xygeni asegura CI/CD pipelinecentrándose en Cómo se manejan, utilizan y exponen los secretos en el mundo real Flujos de trabajo de DevOps. No se trata solo de escanear código; se trata de aplicar las mejores prácticas de gestión de Secreto mediante... pipeline análisis.
Detección de uso de salida inseguro
- Escanea acciones de GitHub para usos de echo, ejecutar y salidas donde ${{ steps.*.outputs.* }} Podría incluir valores sensibles
- Identifica cuándo se hace referencia a los Secretos o se imprimen directamente, intencionalmente o por error.
Monitoreo de Secretos filtrados
- Detecta valores de alta entropía (claves API, tokens) dentro de registros y salidas de pasos
- Activa alertas cuando aparecen secretos en el pipeline registros, incluso si están enmascarados aguas abajo
Uso de acción mal configurado
- Realiza un seguimiento de todas las acciones de GitHub pipelines para detectar el uso de versiones comprometidas (por ejemplo, tj-actions/archivos-cambiados@v45)
- Audita patrones de coincidencia de archivos que incluyen posibles secretos como **/*.env, *.key o .env.*
IC basada en políticas Guardrails
- Aplica la fijación SHA para acciones de terceros
- Bloquea el uso de archivos no seguros que podrían arrastrar Secretos a los registros
- Evita pipelines de emitir valores sensibles como parte de las salidas del flujo de trabajo
Al tratar los flujos de trabajo como parte de su superficie de amenaza, Xygeni garantiza que la higiene de Secreto no sea solo una mejor práctica, sino una defensa incorporada.
Conclusión: La fuga de Secreto puede comenzar con una simple acción de mal uso
CVE-2025-30066 no era un error de biblioteca; era un CI/CD Falla de diseño derivada del uso inadecuado de tj-actions/changed-files. Lo que los equipos de DevSecOps deberían aprender:
- Tratar cada referencia glob/archivo en CI como un punto de fuga potencial
- Audite los flujos de trabajo periódicamente para detectar la inclusión accidental de Secretos
- Utilice bóvedas seguras o entornos Secretos, nunca guarde Secretos en el control de versiones
- Desinfectar o filtrar todas las salidas del flujo de trabajo
- Registrar la actividad confidencial del flujo de trabajo para mantener la auditabilidad
La CI es código. Los flujos de trabajo son código. Los registros y las salidas son código. Protege tus secretos en cada paso o arriésgate a una fuga de secretos que no requiere un hacker, solo un malicioso. CI/CD elección de diseño.
