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.
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.
- Tú
Abres el PR o subes a la rama principal.
Como siempre. Nada que instalar ni recordar.
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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
pusha la rama por defecto (escaneo completo),pull_requesthacia ella (solo OSV-Scanner y el bloqueo de malware) yworkflow_dispatch. Nuncapull_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/escaneoscon un tokenvbt_…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.
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@maino@v1en 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 unGITHUB_TOKENcon 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.
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
- El código que te escribe la IA SAST
- Las librerías que no elegiste SCA
- El paquete que no es el que parece Malware en dependencias
- La clave que se fue en un commit Secrets detection
- Tu infraestructura y tus contenedores IaC · Container scanning · SBOM
- Alguien lee cada aviso AI triage · Reachability
Del ruido a la decisión
Conecta un repo y mira qué hay que corregir. Sin hablar con nadie.