Detector de abuso en CI/CD con IA: cómo frenar ataques con credenciales robadas

Introducción

En el 2023, el 62% de los incidentes de supply chain comprometedieron pipelines de CI/CD mediante credenciales robadas, según datos de la CNCF. Los atacantes modificaban archivos de workflows para extraer secretos almacenados en variables de entorno o tokens de servicios cloud. El problema no es la falta de herramientas, sino la detección temprana: el 78% de estos cambios pasaban desapercibidos en revisiones manuales, según un estudio de GitHub Security Lab.

Elastic Security Labs respondió con CI/CD Abuse Detector, un proyecto open source que automatiza el análisis de cambios en pipelines usando un modelo de lenguaje (Claude) en tiempo de pull request. La herramienta no solo identifica patrones maliciosos conocidos, sino que interpreta el contexto de las modificaciones para detectar técnicas de evasión, como inyecciones de código camufladas en cambios legítimos. Esto reduce la ventana de exposición de credenciales en entornos CI/CD desde horas (o días) a minutos.

Qué ocurrió

El equipo de Elastic Security Labs publicó en junio de 2025 el repositorio CI/CD Abuse Detector como parte de su investigación «Detecting CI/CD pipeline abuse with LLM-augmented analysis». El proyecto surgió tras analizar 143 incidentes reales donde atacantes usaron credenciales comprometidas para modificar workflows en repositorios públicos y privados.

La herramienta surgió como respuesta a un vector de ataque documentado en el CVE-2024-37990, donde un actor malicioso usó un token de GitHub Actions robado para modificar un pipeline y extraer secretos de AWS almacenados en AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY. En ese caso, el cambio fue detectado 3 días después de la ejecución, cuando el costo ya era irrecuperable.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps, el impacto principal es la reducción de riesgos en supply chain. La herramienta analiza automáticamente cambios en archivos críticos como:

• github/workflows/*.yml (GitHub Actions)
• .gitlab-ci.yml (GitLab CI)
• azure-pipelines.yml (Azure DevOps)

Para infraestructura cloud, evita fugas de secretos en entornos CI, donde variables como DOCKER_PASSWORD o SONARQUBE_TOKEN pueden ser expuestas. Según Elastic, el 41% de los equipos de cloud no auditan cambios en pipelines, lo que deja una brecha explotable.

En seguridad, el detector actúa como un guard rail antes de que los cambios maliciosos se ejecuten. El modelo de lenguaje (Claude) evalúa no solo patrones de texto, sino el contexto semántico. Por ejemplo, detecta cuando un cambio agrega un paso que:

1. Usa curl para enviar datos a un endpoint externo.
2. Incluye una variable de entorno no documentada.
3. Modifica permisos de GITHUB_TOKEN para escalar privilegios.

El riesgo se cuantifica con un score de severidad (0-100) basado en reglas como:

• Alto (80-100): Inyección de código que exfiltrará secretos.
• Medio (50-79): Modificación de permisos de tokens.
• Bajo (0-49): Cambios en configuraciones menores (ej: actualización de versiones).

Detalles técnicos

Arquitectura y flujo de análisis

El detector opera en 6 etapas, implementadas en un workflow reutilizable para GitHub Actions, GitLab CI y Azure DevOps:

1. Filtrado de archivos: Usa jq y grep para identificar archivos modificados que coinciden con patrones de CI/CD:

   - name: Filter CI/CD files
     run: |
       changed_files=$(git diff --name-only ${{ github.event.pull_request.base.sha }}..${{ github.event.pull_request.head.sha }})
       echo "$changed_files" | grep -E '\.(yml|yaml|json)$' | grep -E 'workflows?/|.gitlab-ci\.yml|azure-pipelines\.yml'
   

1. Diferenciación controlada: Cada diff se limita a 10,000 caracteres para evitar bypasses que oculten código malicioso en cambios benignos largos.

1. Prescreening: Aplica reglas de regex y metadatos para etiquetar cambios con contexto:

   # Ejemplo de regla: detectar adición de variables no documentadas
   grep -q 'env:' .gitlab-ci.yml && grep -q 'new_secret:' .gitlab-ci.yml
   

1. Análisis con Claude: Los diffs y etiquetas se envían al Claude Code CLI (versión 1.4.0) mediante:

   claude analyze --prompt-file prompt.md --input diff.json --output verdict.json
   

1. Generación de veredicto: El output sigue un schema JSON definido:

   {
     "severity": 85,
     "type": "credential_harvesting",
     "evidence": "Added step to exfiltrate AWS_ACCESS_KEY_ID via curl to attacker.com",
     "recommendation": "Reject PR and rotate AWS credentials"
   }
   

1. Notificaciones: Dependiendo de la severidad, el veredicto se envía a:

– Issues de GitHub (con plantilla predefinida).

– Slack (vía webhook, formato rico).

– Elasticsearch (si la severidad supera un umbral configurado).

Dependencias y requisitos

El detector no requiere Python en runtime (solo en herramientas de mantenimiento). Las dependencias críticas son:

• Bash (versión 5.1+): Para preprocesamiento.
• Node.js (v18+): Para instalar el CLI de Claude.
• Claude Code CLI (v1.4.0): Único componente de análisis externo.

Para autenticación:

• Versión open source: Usa una API key de Anthropic.
• Versión enterprise: Requiere un endpoint de Foundry (servicio interno de Elastic) con clave API almacenada como secreto en el repositorio.

Limitaciones y consideraciones

El proyecto es un prototipo de investigación (no un producto oficial de Elastic). Algunas limitaciones clave:

• Soporte limitado: Solo cubre GitHub, GitLab y Azure DevOps (no Bitbucket o Jenkins).
• Costo: Cada análisis con Claude tiene un límite de tokens (default: 10,000). En pruebas internas, Elastic reportó un costo de $0.02 por PR analizado en configuraciones estándar.
• False positives: El modelo puede marcar cambios legítimos como sospechosos si usan patrones similares a técnicas conocidas (ej: uso de curl en pipelines).

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar si el detector aplica a su entorno

El detector es útil para equipos que:

• Usan GitHub Actions, GitLab CI o Azure DevOps.
• Tienen pipelines con acceso a secretos críticos (AWS, Azure, GCP, tokens de APIs).
• No auditan cambios en workflows automáticamente.

Para equipos con pipelines simples (ej: solo compilación de código sin acceso a secretos), el overhead del análisis con IA puede no justificar el beneficio.

2. Implementar el detector en 3 pasos

Paso 1: Copiar los archivos base al repositorio

# Clonar el repositorio del detector
git clone https://github.com/elastic/cicd-abuse-detector.git
cd cicd-abuse-detector

# Copiar los templates a tu repositorio
cp -r templates/* /path/to/tu-repo/.github/workflows/
cp prompts/prompt.md /path/to/tu-repo/
cp schemas/verdict-schema.json /path/to/tu-repo/

Paso 2: Configurar el workflow en tu repositorio

Para GitHub Actions, editar .github/workflows/cicd-abuse-detector.yml:

name: CI/CD Abuse Detector
on:
  pull_request:
    paths:
      - '.github/workflows/**'
      - '.gitlab-ci.yml'
      - 'azure-pipelines.yml'

jobs:
  detect-abuse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Analyze changes
        run: |
          ./cicd-abuse-detector.sh
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          ELASTICSEARCH_WEBHOOK: ${{ secrets.ELASTICSEARCH_WEBHOOK }}

Paso 3: Ajustar umbrales y notificaciones

Editar el archivo config.json (creado al copiar los templates) para configurar:

• Umbral de severidad para fallar PR: fail_threshold: 80
• Umbral para notificar en Slack: slack_webhook_threshold: 60
• Formato de notificaciones: Plantillas personalizables en notifications/.

3. Rotar credenciales sospechosas

Si el detector marca un cambio como severidad ≥ 80, seguir estos pasos:

1. Rechazar el PR y comentar:

   @repo_owner/reviewers: Este cambio modifica permisos de GITHUB_TOKEN para acceder a repositorios privados. Se recomienda rechazar y revisar la configuración de secrets.
   

1. Rotar credenciales expuestas:

   # Para GitHub Actions
   gh secret delete AWS_ACCESS_KEY_ID
   gh secret set AWS_ACCESS_KEY_ID --new-value $(aws secretsmanager get-secret-value --secret-id prod/aws-creds --query SecretString --output text | jq -r .AWS_ACCESS_KEY_ID)
   

1. Auditar el historial de workflows:

   gh api repos/{owner}/{repo}/actions/runs --paginate | jq -r '.workflow_runs[] | "\(.id) - \(.created_at)"'
   

4. Monitorear costos y ajustar

Para equipos con alto volumen de PRs:

• Limitar el análisis a archivos críticos:

  # En cicd-abuse-detector.yml
  - name: Filter critical files
    run: |
      echo "$changed_files" | grep -vE 'test|docs' | grep -E 'workflows?/|.gitlab-ci\.yml|azure-pipelines\.yml'
  

• Usar Foundry en lugar de Anthropic (para reducir costos):

  env:
    FOUNDRY_ENDPOINT: ${{ secrets.FOUNDRY_ENDPOINT }}
    FOUNDRY_API_KEY: ${{ secrets.FOUNDRY_API_KEY }}
  

Conclusión

CI/CD Abuse Detector no es una solución mágica, pero reduce significativamente el riesgo de supply chain attacks mediante credenciales robadas. Su mayor aporte es automatizar el análisis semántico de cambios en pipelines, algo que las herramientas tradicionales (SAST, DAST) no cubren.

Para equipos que ya usan Elasticsearch, integrar el detector con notificaciones automáticas permite centralizar alertas en un solo lugar. Para otros, la opción de Slack o issues de GitHub es suficiente. La clave está en no tratarlo como un «fire and forget»: ajustar umbrales, rotar credenciales sospechosas y monitorear falsos positivos.

Si tu equipo depende de pipelines con acceso a secretos críticos, este detector es un complemento valioso a tus actuales herramientas de seguridad. La versión open source es suficiente para empezar, pero evalúa el costo de Claude en tu volumen de PRs antes de escalar.

FIN