Usamos una cookie propia para mejorar tu experiencia y con fines estadísticos. No se vende ni se comparte ningún dato con los anunciantes.
Análisis estático sobre tus ficheros de workflow. Inyección, actions sin pinear, tokens con exceso de privilegios, deriva OIDC.
Parseamos tus workflows a AST y a grafo de dataflow, y aplicamos nuestros packs de reglas.
Cada vez que interpolas ${{ github.event.* }}, nombres de rama, títulos de PR o cuerpos de issue en un bloque `run:`, estás haciendo shell-injection sobre tu propio pipeline. El escáner marca como contaminado cada input no confiable y lo sigue por cada paso hasta que aterriza en un shell, incluso a través de composite actions.
@v3, @main, @latest, cada ref flotante es un futuro incidente de cadena de suministro. El escáner marca cada action no fijada a un SHA completo, cada action de un publisher no verificado, y la cruza con el feed de actions maliciosas.
Los scopes por defecto de GITHUB_TOKEN son `write` para casi todo. Detectamos `permissions:` sin configurar, scopes amplios que no usas y recomendamos el conjunto mínimo por job.
Identidad federada AWS, Azure y GCP desde GitHub, GitLab y CircleCI. Cazamos patrones `sub` excesivamente amplios, checks de audience ausentes y políticas de confianza que cualquier fork puede asumir.
`echo $SECRET`, secretos pasados como args posicionales, secretos volcados a artefactos, secretos incrustados en capas de contenedor. Detectados estáticamente, antes de que el runner emita una línea.
PRs no confiables escribiendo en caches que ramas protegidas leen. Reutilización de runners self-hosted sin aislamiento. Uploads de artefactos desde contextos no confiables. Toda la clase de CVEs de cache-poisoning posteriores a 2024.
La mayoría de incidentes de pipeline ya se ven en el YAML. Lo leemos como lo lee un atacante.
Los archivos de workflow reciben el mismo escrutinio que tu código de aplicación: parseo AST, propagación de taint, análisis source-to-sink. El modelo de amenazas es específico de pipelines: triggers no confiables, fuentes de actions, scopes de tokens, confianza OIDC, aislamiento de runners.
Parsers de primera clase para los dialectos CI que mueven la mayoría de los pipelines hoy, incluyendo reusable workflows, cadenas `include:` de GitLab y Jenkinsfile (declarativo y scripted Groovy). Nuevos dialectos bajo demanda.
Cada finding aterriza como un comentario inline en la línea YAML problemática, misma superficie que SAST. Sin dashboard nuevo que aprender, sin cola de triaje separada, sin paso de runner privilegiado que instalar.
Conecta GitHub o GitLab. Nuestros escáneres descargan los archivos de pipeline y corren en cada push (o bajo demanda). Nada que instalar en tu CI, sin paso de runner privilegiado. Los findings van al dashboard unificado y a la revisión de tu PR.
Ver todas las integracionesCorrecto. Conecta el repo una vez. Nuestros escáneres leen .github/workflows, .gitlab-ci.yml, Jenkinsfile y el resto directamente, después reportan findings como comentarios inline en la línea problemática y en el dashboard unificado. Sin paso que añadir a tu pipeline, sin runner privilegiado que instalar.
Workflows de GitHub Actions (incluyendo composite y reusable workflows), YAML de GitLab CI (incluyendo cadenas `include:`) y Jenkinsfile (declarativo y scripted Groovy). Las definiciones de action (action.yml más wrappers Dockerfile-action) también se leen, así que se rastrean los flujos de taint cross-action. Otros dialectos se añaden bajo demanda del cliente.
No necesitamos el payload. Marcamos como contaminado cada valor que viene de `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body`, refs de rama y tag desde un fork, y lo seguimos a través de `env:`, `with:`, valores de output y fronteras de composite-action. Si el valor contaminado llega a un bloque `run:`, a un `eval` en actions de JavaScript o a un comando con sustitución de shell, eso es un finding, independientemente de si te han explotado ya o no.
Sí. Cada entrada `uses:` se cruza con el feed de actions maliciosas de OpenSSF, la lista de verified-publishers y nuestras propias heurísticas de typo-squat sobre nombres de actions. Los tags sin fijar se marcan por separado, porque incluso una action legítima se convierte en riesgo de cadena de suministro si no la fijas a un SHA.
Cualquier cosa que coincida con los patrones de entropía y de proveedor de nuestro rule pack de Detección de Secretos también se marca en archivos CI/CD. También detectamos secretos pasados como args posicionales de CLI (visibles en `ps`), secretos volcados al log con `echo` y secretos incrustados en inputs de reusable workflows. Los findings se deduplican con el escáner de secretos para que no los recibas dos veces.
Sí. Parseamos directivas `runs-on:`, detectamos runners con estado de filesystem compartido entre PRs no confiables, marcamos guards tipo `actions/cleanup` ausentes y avisamos sobre jobs que escalan a root o montan el socket de Docker.
Un comando conecta cada agente de coding de tu máquina a CybeDefend: tus reglas de negocio, tus frameworks de cumplimiento y guards que bloquean llamadas destructivas antes de que se disparen.
npx -y @cybedefend/vibedefend@latest install
Claude Code
Cursor
OpenAI Codex
Windsurf
VS Code Copilot