Entrar Pedir acceso a la beta Pedir acceso
El sector lo llamaMalware en dependencias Qué revisa · 3 de 7

El paquete que no es el que parece

Una vulnerabilidad es un descuido. Un paquete malicioso es alguien que quiere entrar. Se cuela con un nombre casi igual al bueno, o con uno que tu IA se inventó y otro registró a propósito. Lo instalas, y ejecuta su código en tu máquina y en tu CI, con tus secretos a mano. Es lo único que Vibethia para en seco.

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

Un nombre casi igual. Un paquete que no es el bueno

Instalar un paquete es ejecutar código de un desconocido. Normalmente ese desconocido es alguien de fiar. A veces no, y no hay forma de notarlo leyendo el nombre.

VibethiaCheck en rojoPaquete malicioso conocido: no se fusiona.

  • El nombre casi igual.

    Dos letras cambiadas en un paquete popular. Lo escribes mal una vez, o tu IA lo escribe mal, y se instala sin protestar.

  • El paquete que la IA se inventó.

    Las IA a veces recomiendan librerías que no existen. Alguien mira cuáles se inventan más, las registra con malware dentro y espera.

  • El bueno, secuestrado.

    Un paquete de fiar cuya cuenta roban, y la siguiente versión lleva un regalo. Pasa a paquetes con millones de descargas.

  • Lo que hace al instalarse.

    No espera a que lo uses: corre al instalar. Lee tus variables de entorno, tus claves de nube, tu token de GitHub. En tu portátil y en tu CI.

Qué hace Vibethia

Si está en la lista, el PR no pasa

Hay una lista pública, mantenida por la comunidad de seguridad, de paquetes que se han confirmado maliciosos. En cada PR, Vibethia compara tus librerías con esa lista. Si hay una, el check se pone en rojo y no se fusiona. No espera al triaje: aquí no hay nada que juzgar.

  • Es lo único que bloquea. Todo lo demás se revisa y se decide con calma. Un paquete malicioso conocido no: se para en el PR, antes de que llegue a la rama principal.
  • El analista no lo puede cerrar. Un aviso de malware nunca sale como falsa alarma por mucho que el código parezca inocente. Se queda hasta que quites el paquete.
  • También las que llegan detrás. No solo lo que instalaste: todo lo que vino con ello, con la versión exacta que tienes fijada.
  • Lo que no detecta, te lo decimos. Un paquete nuevo que nadie ha denunciado todavía no está en la lista, y Vibethia no lo ve. Nadie lo ve con certeza; quien te diga lo contrario te está vendiendo humo.
Qué haces tú

Quitarlo y cambiar las claves

Si el check se pone en rojo, no es una alarma más: es que algo ha podido ejecutarse ya.

  • Quita el paquete. Y comprueba que no vuelve con otra librería que lo traiga detrás.
  • Da por filtrado lo que tuviera a mano. Si se instaló en tu portátil o en tu CI, rota las claves que había en el entorno: la de la nube, la de GitHub, la de pagos. No esperes a saber si las leyó.
  • Mira de dónde salió. ¿Lo escribió la IA? ¿Lo copiaste de un tutorial? Que el equipo lo sepa evita el segundo.
Motor

Los avisos MAL- de OSV, en el PR

No hay heurística ni modelo: es una lista. OSV-Scanner lee los lockfiles y la API de OSV devuelve, entre los avisos, los MAL- de ossf/malicious-packages. El workflow hace fallar el check si hay alguno.

Fuente
ossf/malicious-packages, agregado en OSV con ids MAL-. Comunidad OpenSSF; entradas confirmadas, con la versión exacta.
Cuándo
En cada pull_request hacia la rama por defecto corren solo OSV-Scanner y el bloqueo: nada de SAST ni secretos en el PR. Y en cada push a esa rama, dentro del escaneo completo.
Qué bloquea
Solo MAL-. Un CVE normal no rompe nada. El bloqueo se puede apagar con bloquear_malware: false, y queda dicho en el workflow.
Qué no ejecuta
Nunca pull_request_target: el token del repo no llega a código de un fork.
Triaje
El analista no puede cerrar un MAL-: el guardarraíl lo deja en Corregir hasta que el paquete desaparece del lockfile.
Pipeline
El check lo da vuestro propio workflow en Actions. Vibethia no necesita permisos de escritura en el repo para pararlo.
Límites

Lo que una lista no puede ver

  • No Malware nuevo, no denunciado

    Entre que se publica y alguien lo confirma pasa un tiempo. En esa ventana no hay aviso.

  • No Análisis de comportamiento

    No instalamos el paquete en un entorno aislado ni miramos qué hace su script de instalación. Quien lo hace, lo hace con tasas de falsos positivos que no queremos trasladarte como bloqueo.

  • No Paquetes fuera de los lockfiles

    Lo que se instala en un run: del CI o en un Dockerfile sin pasar por el lockfile no se ve aquí.

  • Todavía no Señales previas a la lista

    Paquete recién publicado, mantenedor nuevo, nombre a una letra de uno popular. Como aviso, nunca como bloqueo. En estudio.

  • Medido Repo de pruebas

    Los casos de malware sembrados están entre los 20 de 20 de dependencias. Los resultados.

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