Entrar Pedir acceso a la beta Pedir acceso
El sector lo llamaSCA Qué revisa · 2 de 7

Las librerías que no elegiste

Instalas una librería y llegan decenas detrás, que no has elegido ni leído. Si una tiene una vulnerabilidad conocida, la vulnerabilidad es tuya. Vibethia las mira todas y, antes de ponértelo a corregir, comprueba si tu código usa de verdad la parte vulnerable.

Léelo en
Para quien programa con IA y quiere entender el riesgo, sin siglas. Para quien ya conoce SCA: motor, cobertura, pipeline y límites.
El riesgo

Una línea tuya, cuarenta y ocho librerías de otros

Cuando tu IA escribe «npm install algo», no instala una cosa: instala esa y todas las que esa necesita. Tú ves una línea en tu fichero. Tu app lleva dentro código de decenas de personas que no conoces, y cada cierto tiempo a alguna de esas librerías se le descubre una vulnerabilidad.

tu app1 librería
Las 48 que llegaron detrás. Dos tienen una vulnerabilidad conocida y publicado: cualquiera puede leer cómo aprovecharlo.

  • La vulnerabilidad es pública.

    Cuando se descubre una vulnerabilidad en una librería, se publica con su número y su explicación para que todo el mundo actualice. Quien ataca también lo lee, y busca apps que no han actualizado.

  • No lo verás en tu código.

    La vulnerabilidad no está en lo que escribió tu IA. Está en una función de una librería que ni sabías que tenías. Leyendo tu repo no aparece.

  • Pero no todos te afectan.

    Una librería puede tener la vulnerabilidad en una función que tu código nunca llama. Esa es la diferencia entre «hay que actualizar hoy» y «apúntalo para cuando toque».

Qué hace Vibethia

Las mira todas y te dice cuáles usas

En cada subida compara la lista exacta de librerías que lleva tu app con las bases públicas de vulnerabilidades conocidas. Y de cada aviso, el analista lee tu código para ver si pasas por la parte vulnerable.

No la usas

VibethiaVigilarLa vulnerabilidad está, pero tu código no pasa por ahí. Actualiza cuando toque.

Sí la usas

VibethiaCorregirLo usas: actualiza a la versión arreglada. Primero en la lista.

Lo valora el analista leyendo tu código, no una regla. Cuando no puede saberlo, lo dice: «no se sabe», y el aviso se queda a la vista. No se lo inventa.

  • También las que llegan detrás.

    No solo las que instalaste: todas las que vienen con ellas. Y te dice de cuál cuelga cada una, para que sepas qué actualizar.

  • Y los paquetes malos.

    Si una librería está en la lista pública de paquetes maliciosos, no espera al triaje: el PR no pasa. Es lo único que bloquea.

  • Medido, no prometido.

    En nuestro repo de pruebas, con vulnerabilidades sembradas a propósito, encontró los 20 de librerías. Los números, enteros.

Qué haces tú

Actualizar lo que usas. Apuntar lo que no

Cada aviso trae la versión que lo arregla. Lo normal es que actualizar sea una línea y pasar los tests. Cuando no, te lo dice.

  • Corregir: actualiza hoy. Tu código usa la parte vulnerable. Pídele a tu IA que suba la librería a la versión que te indica, pasa los tests y sube el cambio.
  • Vigilar: cuando toque. La vulnerabilidad existe pero no pasas por ahí. Se queda a la vista con prioridad baja; si un día empiezas a usar esa función, el aviso ya está.
  • Si no hay versión arreglada. Pasa. El aviso lo dice, y la decisión es tuya: cambiar de librería, esperar o aislar el uso. Vibethia no te la esconde.
  • Lo que no ves no se puede revisar. Vibethia lee el fichero donde quedan fijadas las versiones exactas (el «lockfile»). Si tu repo no lo tiene, te lo dirá: es lo primero que hay que arreglar.
Motor

OSV-Scanner sobre los lockfiles, sin resolver

Un solo motor para todos los ecosistemas, con la base OSV detrás. Lee versiones exactas, no rangos, y nunca ejecuta tu gestor de paquetes.

Escáner
OSV-Scanner, en vuestras GitHub Actions, con --no-resolve.
Base de avisos
OSV: agrega GHSA, PyPA, RustSec, la de Go y los avisos MAL- de ossf/malicious-packages. Con los alias CVE ↔ GHSA.
Qué lee
Solo lo fijado en los lockfiles: package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, Pipfile.lock, go.sum, Cargo.lock, composer.lock, Gemfile.lock y los demás que admite OSV-Scanner.
Qué no lee
Las transitivas de un requirements.txt o un package.json sin lockfile: sin resolver, no se inventan.
Salida
SARIF, normalizado al mismo esquema que el resto de hallazgos, con huella estable y deduplicado por regla.
SBOM
CycloneDX, lo genera Trivy en el mismo workflow y se adjunta al escaneo.
Contexto

Lo que el workflow manda con cada aviso

El analista no ve el repo: ve lo que preparar_envio saca en el runner, sin IA y con tope. Para una dependencia, esto.

Aviso
Id, alias, resumen, versiones afectadas y la corregida.
Dependencia
Directa o transitiva, de producción o de desarrollo, y el manifiesto del que cuelga.
Usos
Dónde se importa el paquete en vuestro código: los ficheros y líneas que encontró el workflow, con el fragmento alrededor.
Lo que nunca viaja
El repo entero, los secretos sin enmascarar y nada que diga qué respuesta se espera. Lo que viene del repo no puede cerrar un bloque del mensaje.
Alcanzabilidad

La juzga el analista, no un grafo de llamadas

Con los usos delante, el analista responde si vuestro código llega a la parte afectada: sí, no, no se sabe o no aplica. Y lo justifica citando ruta y línea.

  • Sí Alcanzable = sí

    La prioridad sube un nivel dentro de Corregir, sin pasar de crítica. Es lo que va primero en la lista.

  • Sí Alcanzable = no

    Clasificación «improbable»: veredicto Vigilar. Visible, con prioridad baja. Nunca se descarta por no usarse: la vulnerabilidad existe.

  • Sí No se sabe

    Cuando los usos no bastan para decidirlo, lo dice y deja falta_contexto. No se convierte en un Descartar.

  • No Análisis estático de alcance

    No construimos un grafo de llamadas ni ejecutamos nada. Es una lectura con criterio, con sus límites: por eso la justificación es obligatoria y se puede corregir a mano.

Pipeline

Dónde corre y qué bloquea

Los escáneres corren en vuestras Actions con un workflow reutilizable; a Vibethia llega el SARIF y el contexto, por API y con un token por repo. Nada se clona en nuestras máquinas.

  • Sí Push a la rama principal

    Escaneo completo. El triaje corre en el worker a los minutos y el panel se actualiza.

  • Sí Pull request

    Solo el bloqueo de malware conocido (MAL-): si una dependencia está en la lista, el check falla. Nada más frena el merge.

  • Todavía no Escaneo completo en el PR

    En camino. Hoy la lista completa llega tras el push a la rama principal.

  • Todavía no Bloqueo por política

    Frenar el merge por severidad o veredicto, por repo. En camino.

Límites

Lo que esta capa no hace

  • No Licencias

    No clasifica licencias ni avisa de incompatibilidades.

  • No Fin de vida

    No avisa de versiones o runtimes sin mantenimiento.

  • No PR de actualización automático

    Da la versión corregida y el prompt. Para el PR automático seguid con Dependabot o Renovate: no compiten.

  • No Registros privados

    Un paquete interno que no esté en OSV no tiene avisos. Se lista en el SBOM, sin más.

  • Medido Repo de pruebas

    20 de 20 vulnerabilidades sembradas en dependencias, igual que el plan gratuito de Xygeni. La comparativa entera.

Lo demás que revisa

Del ruido a la decisión

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

Pedir acceso a la beta