Webinar en inglésWebinar con Jason Lee, mié, 14 octYour newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkInscríbete

Tus pipelines son código. Por eso los leemos.

Tus archivos de workflow leídos como código: inyección, actions sin fijar, tokens y confianza, cada uno con su corrección.

Probar el cloudVer VibeDefend
checkout-apiCI/CDProyecto de demostración
  • CríticaInyección en un workflowrelease.yml:24

    El título de la pull request llega a run: en el shell.

    run: echo "${{ github.event.pull_request.title }}"env:  TITLE: ${{ github.event.pull_request.title }}run: echo "$TITLE"

    Corrección listaEl título pasa a una variable de entorno, fuera del shell.

Los fallos del pipeline, encontrados en el archivo.

  • Inyección en un workflow

    • ${{ github.event.pull_request.title }}

  • Actions sin fijar

    • actions/checkout@v3
    • actions/setup-node@main

  • Tokens con demasiados privilegios

    • permissions: write-all

  • Confianza OIDC

    • "sub": "repo:acme/*"

La inyección, corregida en el workflow.

Tal como está escrito

run: echo "${{ github.event.pull_request.title }}"

El título de la pull request llega a run: en el shell.

Con la corrección

env:  TITLE: ${{ github.event.pull_request.title }}run: echo "$TITLE"

El título pasa a una variable de entorno, fuera del shell.

Corregido por tu agente, en la sesión.

Tu agente lee estos hallazgos mientras escribe y los corrige en la misma sesión.

Ver VibeDefend
  1. CI/CDEscanea el repositorio en cada push.Detectado
  2. VibeDefendLe pasa el hallazgo a tu agente de código.Servido
  3. Tu agenteLo corrige en la sesión.Corregido
  4. CommitEntra sin el fallo.Limpio
  • Claude Code
  • Cursor
  • Windsurf
  • GitHub Copilot
  • OpenAI Codex

Empieza por un repositorio.

Conecta GitHub, GitLab, Bitbucket o Azure DevOps, elige un repositorio y el primer escaneo arranca.

Probar el cloudReservar una demo

En detalle

Seis fallos de pipeline, encontrados en el archivo.

  • Inyección en un workflow

    Datos de eventos, nombres de rama o títulos de pull request que llegan a un bloque run:.

    CWE-77, CWE-78

  • Actions sin fijar

    @v3, @main, @latest: cada referencia flotante es un futuro incidente de supply chain.

  • Tokens con demasiados privilegios

    Sin bloque permissions:, o con permisos de escritura que un job nunca usa.

  • Confianza OIDC

    Identidad federada de GitHub, GitLab o CircleCI hacia AWS, Azure y GCP, concedida de forma demasiado amplia.

  • Fugas de secretos

    echo $SECRET, secretos pasados como argumentos, olvidados en artefactos o en capas de imagen.

  • Envenenamiento de caché y artefactos

    Pull requests no fiables que escriben en cachés que leen las ramas protegidas.

Todo lo que revisa

Caza la mala configuración antes de que corra el runner.

La mayoría de los incidentes de pipeline ya se ven en el YAML. Lo leemos como lo leería un atacante.

  • Pipelines tratados como código

    Los archivos de workflow se examinan con el mismo rigor que el código de tu aplicación: análisis del AST, propagación de taint y análisis de source a sink.

  • GitHub Actions, GitLab CI, Jenkinsfile

    Parsers dedicados para los dialectos de CI en los que hoy se escriben la mayoría de los pipelines, incluidos los workflows reutilizables, las cadenas include: de GitLab y Jenkinsfile (Groovy declarativo y scripted).

  • Los hallazgos, en la PR

    Cada hallazgo llega como comentario en la línea del YAML afectada, en el mismo sitio que los de SAST.

Seis fallos, leídos en el archivo.

Convertimos tus workflows en un AST y un grafo de flujo de datos, y les aplicamos nuestros propios packs de reglas.

  • Inyección en workflows (CWE-77 / 78)

    Cada vez que interpolas ${{ github.event.* }}, nombres de rama, títulos de PR o el texto de las issues en un bloque run:, abres la puerta a una inyección de shell en tu propio pipeline.

  • Actions sin fijar y no confiables

    @v3, @main, @latest: cada referencia flotante es un futuro incidente de supply chain.

  • Tokens con privilegios excesivos

    Por defecto, los permisos de GITHUB_TOKEN son write para casi todo. Detectamos permissions: sin definir y permisos amplios que no usas, y recomendamos el mínimo necesario para cada job.

  • Confianza OIDC mal configurada

    Identidad federada con AWS, Azure y GCP desde GitHub, GitLab y CircleCI.

  • Patrones de fuga de secretos

    echo $SECRET, secretos pasados como argumentos posicionales, secretos volcados en artefactos, secretos incrustados en capas de contenedor.

  • Envenenamiento de cache y artefactos

    PR no confiables que escriben en cachés que leen las ramas protegidas. Runners autoalojados reutilizados sin aislamiento.

Del YAML a la corrección

  • El YAML es inseguro.

    Trigger inseguro, escritura, action sin fijar.

  • Juzgado antes de correr.

    Estático, sobre el propio archivo, sin pipeline.

  • Fijado y acotado.

    SHA fijado, permisos de lectura, entradas aisladas.

Conecta el repo, el resto es automático.

Conecta GitHub o GitLab. Nuestros escáneres leen los archivos de pipeline y se ejecutan en cada push (o bajo demanda). Nada que instalar en tu CI, ningún paso con runner privilegiado. Los hallazgos llegan al dashboard unificado y a la revisión de tu PR.

Seis dialectos de CI alimentan un solo parser: GitHub Actions, GitLab CI, Bitbucket, Azure DevOps, Jenkins, CircleCI.

El commit a3f9c2e toca release.yml. Dos ejecuciones salen del build: #4821 y #4822.

En la barrera, release.yml se lee como lo leería un atacante: trigger, permisos, cada uses: y run:.

#4821 queda bloqueada: pull_request_target con contents: write y una action sin fijar nunca llegan al job de deploy.

#4822 sale a prod-eu: SHA fijado, token de solo lectura, el título de la PR fuera del shell.

Preguntas frecuentes sobre el escáner CI/CD.

¿CybeDefend analiza mis archivos de pipeline sin ser un paso dentro del pipeline?
Exacto. Conectas el repositorio una sola vez. Nuestros escáneres leen directamente .github/workflows, .gitlab-ci.yml, Jenkinsfile y el resto, y publican los hallazgos como comentarios en la línea afectada y en el dashboard unificado. No hay que añadir ningún paso a tu pipeline ni instalar un runner privilegiado.
¿Qué formatos de pipeline admite CybeDefend?
Workflows de GitHub Actions (incluidas las actions compuestas y los workflows reutilizables), YAML de GitLab CI (incluidas las cadenas `include:`) y Jenkinsfile (Groovy declarativo y scripted). También leemos las definiciones de actions (action.yml y los wrappers de Dockerfile), así que seguimos los flujos de taint entre actions. Añadimos otros dialectos a petición de los clientes.
¿Cómo se detecta una inyección en workflows si solo se dispara con ciertos payloads de eventos?
No necesitamos el payload. Tratamos como no confiable cada valor que llega de `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body` y de las refs de rama y de tag de un fork, y lo seguimos a través de `env:`, `with:`, los valores de output y los límites de las actions compuestas. Si ese valor llega a un bloque `run:`, a un `eval` en una action de JavaScript o a un comando con sustitución de shell, es un hallazgo, te hayan atacado ya o no.
¿Detecta CybeDefend GitHub Actions maliciosas o con typosquatting?
Sí. Cada entrada `uses:` se cruza con el feed de actions maliciosas de OpenSSF, la lista de publishers verificados y nuestras propias heurísticas de typosquatting sobre los nombres de las actions. Los tags sin fijar se señalan aparte, porque hasta una action legítima se convierte en un riesgo de supply chain si no la fijas a un SHA.
¿Y los secretos en archivos de workflow?
Todo lo que coincide con los patrones de entropía y de proveedor de nuestro pack de reglas de detección de secretos también se señala en los archivos de CI/CD. Además detectamos secretos pasados como argumentos posicionales de la CLI (visibles en `ps`), secretos escritos en los logs con `echo` y secretos incrustados en los inputs de workflows reutilizables. Los hallazgos se deduplican con los del escáner de secretos para que no te lleguen dos veces.
¿Se pueden analizar las configuraciones de runners autoalojados?
Sí. Analizamos las directivas `runs-on:`, detectamos runners que comparten el estado del sistema de archivos entre PR no confiables, señalamos la ausencia de controles del tipo `actions/cleanup` y avisamos de los jobs que escalan a root o montan el socket de Docker.