Seguro del código a la nube.

Producto estrella

VibeDefend

Aprende las reglas de tu proyecto, vigila cada prompt y deja que el agente escriba código seguro desde el principio.

Descubrir VibeDefend

Agentes de IA

Escáneres

Gobernanza

Ver la plataforma completa

Desarrolladores

Recursos

Investigación

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

Análisis estático de tus archivos de workflow: inyecciones, actions sin fijar, tokens con demasiados privilegios y deriva de OIDC.

Reserva una demo de 30 min

commita3f9c2e · release.yml

build#4821 · #4822

control CybeDefendrelease.yml read

deployprod-eu

bloqueadapull_request_target · contents: writedesplegadauses: @7a3c…e4f · contents: read

commita3f9c2e · release.yml

build#4821 · #4822

control CybeDefendrelease.yml read

deployprod-eu

bloqueadapull_request_target · contents: writedesplegadauses: @7a3c…e4f · contents: read

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.

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.

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.

permissions: write-all

permissions:

contents: read

id-token: write

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

runs-on: self-hosted

runs-on: ubuntu-24.04

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

uses: actions/checkout@v3

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

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

role/deploy › trust policy › sub

repo:acme/*

repo:acme/api:environment:production

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.

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

env:

TITLE: ${{ github.event.pull_request.title }}

run: echo "$TITLE"

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

run: ./publish.sh ${{ secrets.NPM_TOKEN }}

env:

NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

run: ./publish.sh

Pasa el cursor por una línea marcada para ver su corrección.Toca una nota para ver su corrección.

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.

.github/workflows/release.yml:12source
message: ${{ github.event.pull_request.title }}
.github/workflows/notify.yml:4hop
message: { type: string }
.github/workflows/notify.yml:10sink
run: echo "${{ inputs.message }}"

cybedefendcommented onnotify.yml:10

pull_request.title reaches run: through inputs.message.

run: echo "${{ inputs.message }}"

env: { MSG: "${{ inputs.message }}" }

run: echo "$MSG"

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.