El sector lo llamaCI/CD security Qué revisa · 6 de 7

Tu CI y tu pipeline

El CI es la cadena de montaje de tu app: lo que se sube pasa por ahí antes de llegar a producción. Vibethia se engancha a esa cadena en tu propio repo, sin pedirte el código, y además revisa la cadena misma: las acciones de terceros que ejecutas con tus secretos a mano.

Léelo en
Para quien programa con IA y quiere entender el riesgo, sin siglas. Para quien ya conoce CI/CD security: motor, cobertura, pipeline y límites.
Cómo encaja

Vive en tu CI. No en nuestras máquinas

No clonamos tu repo. Un fichero en tu carpeta de workflows hace que los escáneres corran en tus propias GitHub Actions, y solo los avisos (con el trozo de código señalado, ya tapado) viajan a Vibethia. Lo mismo que hacen las herramientas grandes; sin que el código salga de GitHub.

  1. Tú

    Abres el PR o subes a la rama principal.

    Como siempre. Nada que instalar ni recordar.

  2. Tu CI

    Corre el workflow de Vibethia, junto a tus tests.

    En un PR, solo la comprobación de malware. En la rama principal, la revisión completa: código, librerías, claves y configuración.

  3. Tu CI

    Manda a Vibethia los avisos y los trozos de código señalados.

    Ya enmascarados, con un token que solo sirve para ese repo. El repo entero no sale de GitHub.

  4. Vibethia

    Ordena, quita lo repetido y tría cada aviso.

    A los minutos tienes en el panel la lista corta: qué corregir, qué revisar, qué vigilar.

  5. Tú y tu IA

    Pegas el arreglo y vuelves a subir.

    La siguiente subida reconoce lo que ya estaba y marca lo que se ha corregido.

Qué bloquea

Casi nada. A propósito

Una herramienta que para el PR cada vez que ve algo se desactiva en una semana. Vibethia solo frena una cosa: un paquete malicioso conocido. Lo demás te llega como lista para decidir, no como muro.

  • Bloquea Malware conocido en una librería

    El check del PR se pone en rojo y no se fusiona. No hay nada que juzgar.

  • No bloquea Vulnerabilidades de código, claves, configuración

    Van al panel con su veredicto. Tú decides si lo arreglas antes de fusionar o después.

  • Todavía no Frenar por tu propia regla

    «Nada crítico pasa a producción», por repo. En camino. Hoy, la lista; mañana, si quieres, el muro.

La cadena misma

El CI que ejecuta código de otros

Tu pipeline usa acciones de terceros, con acceso a tus secretos. Si apuntan a una rama y no a una versión fija, mañana pueden hacer otra cosa. Y si un paso ejecuta el título de un PR como si fuera un comando, cualquiera que abra un PR manda en tu CI.

«@main» es lo que haya hoy en esa rama. El hash es siempre lo mismo.
VibethiaVigilarAcción de CI sin fijar a una versión.
  • La acción sin fijar.

    Si la cuenta de quien la publica cae en malas manos, la siguiente ejecución de tu CI ejecuta lo que ellos quieran, con tus secretos. Fijarla a un hash lo evita.

  • El texto que se ejecuta.

    Un paso que mete el título de un PR o un comentario dentro de un comando. Quien escribe el título, escribe el comando. Vibethia te marca el paso.

  • Nuestro propio workflow.

    Predicamos con el ejemplo: las imágenes de los escáneres van fijadas por hash, y el workflow no ejecuta nunca código de un fork con tu token.

Workflow

Un workflow reutilizable, un token por repo

Las Actions del cliente, como Xygeni. El workflow llama al reutilizable de Vibethia, corre los cuatro escáneres, prepara el envío sin IA y hace un POST a la API. Nada corre en nuestras máquinas.

Disparadores
push a la rama por defecto (escaneo completo), pull_request hacia ella (solo OSV-Scanner y el bloqueo de malware) y workflow_dispatch. Nunca pull_request_target.
Escáneres
Semgrep, OSV-Scanner, Gitleaks y Trivy, en contenedores fijados por digest. Cada uno deja su versión y su estado; si uno falla, el envío lo dice en vez de callar.
preparar_envio
Una acción sin dependencias que corre en el runner: saca los fragmentos, enmascara secretos, localiza dónde se importa cada paquete y, si está activado, el mapa de lógica con tope de tamaño.
Envío
POST /api/v1/escaneos con un token vbt_… por repo, guardado como secreto del repo; Vibethia solo conserva su SHA-256. Ingestión síncrona y determinista, en una transacción; el triaje nunca va en la petición.
Alta
Con la GitHub App: crea el token, lo guarda como secreto y abre el PR con el workflow. Sin la app, alta a mano con el mismo fichero.
Coste en Actions
Minutos de vuestro CI, como cualquier otro job. Los contenedores están cacheados por digest; el escaneo completo de un repo mediano son unos pocos minutos.
Seguridad del pipeline

Lo que se revisa del propio CI

Las reglas de GitHub Actions del paquete por defecto de Semgrep corren sobre .github/workflows en cada escaneo completo. Lo hemos comprobado contra un workflow de prueba antes de escribir esta página.

  • Sí Acciones de terceros sin fijar

    uses: x/y@main o @v1 en lugar de un SHA: tag mutable. Un hallazgo por paso.

  • Sí Inyección en run:

    ${{ github.event.* }} controlado por quien abre el PR o comenta, interpolado en un shell.

  • No Permisos del token por job

    No audita permissions: ni avisa de un GITHUB_TOKEN con más alcance del necesario.

  • No Otros CI

    GitLab CI, Jenkins, CircleCI. Solo GitHub Actions, y solo repos en GitHub.

  • Todavía no Escaneo completo en el PR

    Hoy el PR solo lleva el bloqueo de malware; la lista completa llega tras el push a la rama principal. En camino.

  • Todavía no Bloqueo por política y atestaciones

    Frenar el merge por severidad o veredicto; firmar lo que sale del pipeline. En camino.

Datos

Qué viaja y qué no

Lo que sale de vuestro repo es el SARIF de cada escáner (saneado), los fragmentos enmascarados alrededor de cada línea señalada, los usos de cada dependencia con aviso y, si lo activáis, el mapa de lógica con tope. Nunca el repo entero, nunca un secreto sin tapar. El recorrido completo, con quién trata qué, está en Seguridad y datos.

Lo demás que revisa

Del ruido a la decisión

Conecta un repo y mira qué hay que corregir. Sin hablar con nadie.