Paquetes npm maliciosos que evitan el escaneo durante la instalación
Un hilo técnico repasa el caso de paquetes que no disparan nada al instalarse y solo actúan en tiempo de ejecución, con el análisis de comportamiento como única defensa real.
Los paquetes maliciosos de npm que no ejecutan nada durante la instalación y esperan al tiempo de ejecución han vuelto al centro del debate esta semana, a raíz de un hilo de comentarios que cita un informe sobre el asunto. El consejo que se repite es no fiarse solo del escaneo en el momento de instalar y añadir análisis del comportamiento en ejecución.
Escanear al instalar ya no basta
La mayor parte del tooling que hoy se coloca delante de un registro npm mira lo que resulta fácil de mirar: los hooks de instalación, el package.json, las dependencias declaradas. Un paquete que no hace nada raro hasta que alguien lo importa se salta esa barrera sin despeinarse, porque el código que importa vive en el camino de ejecución, no en el instalador. Quien solo valide artefactos antes de abrirlos está dejando la puerta abierta a todo lo que se activa después.
Ahí entra Clive Robinson, habitual en los comentarios del hilo, que recuerda que él ya escribió sobre esto hace años bajo el nombre de castillos frente a prisiones. Su argumento: revisar el artefacto antes de ejecutarlo es un castillo, y lo que hace falta es una prisión con un hipervisor observando qué toca el proceso y cómo altera las firmas del software legítimo, con métodos probabilísticos. Hoy eso se vende como análisis de comportamiento en tiempo de ejecución, aunque en su opinión se queda corto respecto a lo que daría un confinamiento bien diseñado.
Mucho ruido alrededor
El resto del hilo es otra cosa. Un comentarista descarga su irritación contra JavaScript y contra el hecho de que se cuele hasta en sitios donde no hace ninguna falta, y echa de menos que las dependencias de un proyecto se puedan desenredar sin romper medio sistema al desinstalar algo. Robinson le sigue con que lleva años señalando los problemas de seguridad del código que se ejecuta en el cliente y con que el W3C insiste en meter ejecutables en las especificaciones del navegador. Es una discusión vieja, con poca sustancia nueva: quien administre sistemas no va a encontrar aquí nada que no haya leído antes.
El interés práctico es concreto. Si el pipeline solo inspecciona el momento de la instalación, hay un punto ciego, y los procesos de Node tienen red, credenciales y acceso al sistema de archivos. El hilo, eso sí, no da nombres de paquetes ni versiones afectadas: eso queda en el informe enlazado. Y la recomendación de vigilancia en ejecución tiene un coste operativo que nadie detalla: instrumentar cada contenedor no es gratis ni en CPU ni en ruido de alertas.