Un escáner CI/CD dedicado. Análisis estático sobre los archivos de workflow en tu repo: workflow injection, actions sin pinear, tokens con privilegios excesivos, drift de OIDC. Detectado antes de que ningún runner coja el job.
Nuestros escáneres parsean tus configuraciones de pipeline a un AST y un grafo de dataflow, después corren rule packs propios informados por OpenSSF Secure Workflows, los playbooks de StepSecurity y nuestra propia investigación sobre incidentes de envenenamiento reales. Los findings van al dashboard unificado junto a SAST, SCA, IaC, Secretos y Container.
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 contamina 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 pineada a un SHA completo, cada action de un publisher no verificado, y 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 logueados en artefactos, secretos cocidos 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 los incidentes de pipeline son visibles en el YAML. Lo leemos como lo lee un atacante, estáticamente, con contexto completo de dataflow, para que el finding aterrice en la revisión de la PR, no en una retro post-incidente.
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 tiran 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. Contaminamos 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:`, un `eval` en actions de JavaScript o 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 pinear se marcan por separado, porque incluso una action legítima se convierte en riesgo de cadena de suministro si no la pineas 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 logueados via `echo` y secretos cocidos 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.
Sin tarjeta. Sin llamada de configuración. Elige tu agente, pega el comando, y Cybe aplica tus reglas desde el siguiente prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpMCP alojado, sin instalación. Solo registra la URL en tu agente.